Guia Completa Doble Faz

GUIAS PARA DISEO E IMPLEMENTACION DE
Portales Estatales
BUENAS PRCTICAS Versin 1.0 2009

Este documento ha sido elaborado por AGESIC (Agencia para el Desarrollo del Gobierno de Gestin Electrnica y la Sociedad de la Informacin y el Conocimiento) Usted es libre de copiar, distribuir, comunicar y difundir pblicamente este documento as como hacer obras derivadas, siempre y cuando tengan en cuenta citar la obra de forma especfica y no utilizar esta obra para fines comerciales. Toda obra derivada de esta deber ser generada con estas mismas condiciones.
Mejoremos el acceso al Estado a travs de un mejor desarrollo de la Web

Un portal de gobierno es un medio de comunicacin muy importante y abre a la organizacin una gran cantidad de posibilidades para facilitar actividades de difusin, sensibilizacin, capacitacin, participacin y servicios en lnea. El portal no suplantar a otros medios de comunicacin pero s constituye un complemento que permite facilitar el acceso a la informacin y los servicios a todos los ciudadanos. Al desarrollar un portal nos encontramos con que debemos tener en cuenta: las necesidades de la organizacin, las expectativas de nuestro pblico objetivo, cul es el mensaje a comunicar, la calidad de los contenidos, los requerimientos y limitaciones tecnolgicas, la creatividad y el diseo, la imagen corporativa, criterios de usabilidad, criterios de accesibilidad, las normas legales que se deben cumplir, los cuidados que tenemos que tener para no infringir derechos de propiedad intelectual, el equipo de trabajo que permitir llevarlo adelante, la posterior gestin de los contenidos y los procedimientos de publicacin, aprobacin y control de calidad. Pero por encima de todas las cosas se encuentra la obligacin de disear una Web para todos. Esta gua fue pensada como material de apoyo para los equipos que tienen la responsabilidad de disear e implementar portales estatales. La misma rene un conjunto de buenas prcticas y recomendaciones donde se incluyen conceptos de planificacin, diseo, implementacin, usabilidad, accesibilidad, normativa y seguridad.
Captulo I
Planificar y Desarrollar un portal
Captulo I Desarrollar un portal | 7
Planificar y desarrollar un portal
Este captulo est pensado para aquellas personas que estn planificando desarrollar un nuevo portal para su organizacin o re-disear el existente. Tiene como objetivo poner a disposicin una serie de recomendaciones que le permitirn cubrir los aspectos importantes que debe tener en cuenta en su proyecto. Esta gua no est destinada solo a personal del rea informtica, es para cualquier persona que de alguna forma est involucrada en el desarrollo de portales. Al desarrollar un portal nos encontramos con que debemos compatibilizar estos conceptos: las necesidades de la organizacin, las expectativas de nuestro pblico objetivo, cul es el mensaje a comunicar, la calidad de los contenidos, los requerimientos y limitaciones tecnolgicas, la creatividad y el diseo, la imagen corporativa, criterios de usabilidad,
8 | Captulo I Desarrollar un portal
criterios de accesibilidad, las normas legales que se deben cumplir, los cuidados que tenemos que tener para no infringir derechos de propiedad intelectual, el equipo de trabajo que permitir llevarlo adelante, la posterior gestin de los contenidos y los procedimientos de publicacin, aprobacin y control de calidad. Muchas veces por la urgencia, porque no se disponen de equipos multidisciplinarios, o por falta de recursos no llegamos a controlar todos estos puntos, es por eso que deseamos que este documento sirva de apoyo para poder tenerlos en cuenta independientemente de las limitaciones que tenga en su proyecto. Dentro de este documento no consideraremos las actividades de gestin de proyectos, aunque si es til tomar como punto de partida la lista de actividades genrica que deberemos realizar para lograr la puesta en produccin del nuevo portal:
Ejemplo de plan de actividades

Proyecto Nuevo Portal 1. Relevamiento interno: objetivos, pblico a atender, expectativas, benchmarking, contenidos a incluir. 2. Relevamiento de diseo 3. Diseo de la nueva arquitectura de los contenidos 4. Diseo de los bocetos o wireframes 5. Aprobacin por la organizacin de los bocetos
6. Devolucin al diseador para la realizacin de ajustes 7. Inicio del plan de desarrollo de contenidos 8. Maquetacin del nuevo portal 9. Implementacin del portal 10. Carga y/o migracin de contenidos a. Determinar procedimiento b. Disear formulario para recoleccin de contenidos c. Definicin de roles y permisos 11. Validacin del nuevo portal por el equipo de desarrollo 12. Testeo de Seguridad por el equipo encargado de infraestructura 13. Validacin del portal por la organizacin 14. Devolucin para ajustes 15. Capacitacin al equipo de gestin de contenidos y administracin del portal 16. Validacin final y ajustes a los contenidos 17. Puesta en Produccin
Comenzando a trabajar
Un portal de gobierno es un medio de comunicacin muy importante y abre a la organizacin una gran cantidad de posibilidades para facilitar actividades de difusin, sensibilizacin, capacitacin, participacin y sobre todo para colocar servicios en lnea. El portal no suplantar a otros medios de comunicacin pero s constituye un complemento que permite facilitar el acceso a la informacin y los servicios.
Fuente: Curso de Estrategias de Gobierno Electrnico OEA
Para comenzar este proyecto deber contar con: Equipo de direccin de proyecto La definicin de la estrategia del sitio que desea la organizacin y el nivel de desarrollo a implementar Conocer cul es el pblico objetivo Una idea general de los productos o contenidos que desea priorizar la organizacin Un conjunto de sitios que agradan y un conjunto de sitios que contienen formatos que no agradan.
Equipo de direccin de proyecto

Es importante que el equipo que lidera este proyecto est integrado por personal del rea de informtica y del rea de comunicaciones y que tenga un vnculo directo con los tomadores de decisiones del organismo de manera de poder validar las estrategias a seguir.
Sus actividades deben estar articuladas con todas las reas del organismo de manera de integrar desde el principio sus necesidades y expectativas, integrarlos y orientarlos en el uso de esta herramienta de comunicacin y sus posibilidades. Para esto ser muy importante solicitar la conformacin de un grupo de trabajo con representantes de las diferentes reas que acompaen todo el proceso y cuyo objetivo sea: Colaborar como nexo en el relevamiento de contenidos y necesidades Tener puntos de vista diferentes para validar opciones Disponer de un canal de comunicacin directo con cada una de las reas del organismo. En este tipo de proyectos nos encontramos con que es necesario que interacten diferentes roles: informticos, comunicadores, diseadores web y editores de contenidos. Lograr contar desde el inicio con equipos con estas caractersticas facilita el desarrollo del proyecto.
Estrategia del sitio

Al comenzar a trabajar en el proyecto y previo al relevamiento es importante conceptualizar que nivel de portal est preparada la organizacin para proporcionar y para ello deber determinar: el alcance del proyecto, el pblico objetivo, las expectativas de la organizacin y un estudio de los portales de organizaciones equivalentes que permitan identificar mejores prcticas o aspectos a mejorar.
Nivel de desarrollo del portal del organismo

El nivel de desarrollo del portal deseable considera tres dimensiones, informacin a brindar, nivel de interactividad con el usuario y servicios a disposicin. Sin embargo, estas dimensiones coinciden con el proceso de evolucin de la oferta de contenidos y proceso de madurez de la organizacin. La gran mayora de los portales comienza por la dimensin informacin y con el tiempo incorpora herramientas interactivas y de servicios. A continuacin describimos un ejemplo de cada una de las tres dimensiones y los posibles contenidos a considerar. Los mismos dependern de la organizacin en la que se encuentre y de la capacidad de desarrollo de los mismos.
Dimensiones Tipos de contenidos Corporativa Ejemplo de contenidos misin, polticas y programas, organigrama leyes, estudios, noticias, boletines, esto depender de la organizacin gestin, rendicin de cuentas, auditorias, todo Transparencia lo que permita cumplir con la ley de acceso a la informacin pblica mail o formulario de contacto, encuestas consulta pblica, chat con autoridad, e-mails de profesionales y autoridades foro, chat, diario mural preguntas frecuentes, buscador, manuales, mapa sitio, polticas adoptadas en el sitio gua de trmites, formularios, registro de consultores, proveedores consultora en lnea, capacitacin a distancia, trmites on line
De inters del usuario Informacin
Usuario Sitio
Interactividad
Usuario Institucin Usuario Usuario
Gua bsica
Servicios
Orientacin
Servicio on line
Fuente: Curso de Introduccin a la elaboracin de Estrategias de Gobierno Electrnico de la OEA
Ejemplo
Un portal gubernamental que desarrolla todas las dimensiones planteadas es el del Estado de Nuevo Len en Mxico: http://www.nl.gob.mx
En conjunto con las dimensiones que incorpore al portal deber tener en cuenta el nivel de desarrollo que desee el organismo, en todos los casos deber estar alineado con los principios y lneas estratgicas de gobierno electrnico establecidos en el Dec. Nro. 450/09 - Principios y Lneas Estratgicas para el Gobierno Electrnico en Red. En el cual se establece que los proyectos debern tender al Acceso Universal:
Lnea Estratgica Nro2 - Acceso Universal Se deber promover la generalizacin del uso de las TIC, a travs de iniciativas que garanticen su acceso al conjunto de la poblacin, en idnticas condiciones de acceso, costo y calidad, con independencia de su localizacin geogrfica y condiciones fsicas de movilidad. Se deber propiciar que los proyectos contemplen criterios de: accesibilidad (eliminacin de barreras para usuarios con capacidades reducidas o falta de formacin), usabilidad (disponibilidad de caractersticas y formatos fcilmente reconocibles y utilizables), disponibilidad multicanal (servicios que son ofrecidos por ms de un medio o canal).
Pblico objetivo
Una vez lograda una visin de alto nivel de las dimensiones a atender por el portal, debe identificar cual es el pblico objetivo, que tipo de usuarios acceder al portal y que esperan encontrar en l.
Ejemplo
Supongamos que debemos desarrollar un portal de compras, podemos identificar diferentes tipos de usuarios con diferentes intereses: proveedores que desean ver oportunidades de negocios, organismos que desean ver que se est comprando, otras unidades de compras que pueden buscar ejemplos de procedimientos, organismos de contralor que desean visualizar la transparencia de los procedimientos, ciudadanos en general que tienen derecho a acceder a la informacin de uso de los fondos pblicos.
Con lo cual nuestro portal y la organizacin de los contenidos debern estar pensados para satisfacer las necesidades de los tipos de usuarios identificados: proveedores, organismos y ciudadanos. El ejercicio de imaginarnos los diferentes usuarios, sus expectativas e intentar llegar a que contenidos esperan encontrar, nos permitir en la etapa del diseo tomar las decisiones de cual es la mejor organizacin, como se clasificar la informacin, que reas temticas se debern tener en cuenta, que informacin deber estar accesible desde la portada.
Informacin y productos a difundir

Por otra parte la organizacin tiene productos, servicios o informacin que desea posicionar en el colectivo de los usuarios y que deben estar identificadas claramente porque al igual que las expectativas del usuario hay que satisfacer las expectativas de comunicacin de la organizacin. El equilibrio entre ambos factores es muy importante de encontrar sin perder la visin estratgica de gobierno electrnico.
Ejemplo
Supongamos un sitio de una organizacin que brinda servicios de salud y desea en el nuevo portal imponer los conceptos de prevencin y hbitos saludables, adems de brindar nuevos servicios de consultas en lneas, reserva de consultas a especialista en lnea. Los usuarios accedern esperando encontrar los horarios de los mdicos, la posibilidad de reservas on-line, y al ingresar en los diferentes servicios que buscan encontrarn reas en las que la organizacin tiene informacin fcil de acceder sobre prevencin y hbitos saludables.
Benchmarking
Imaginar el sitio deseado o no deseado es un reto para el equipo de direccin de proyecto y luego para el equipo de diseo. Una actividad que ayuda es realizar un relevamiento de aquellos sitios de organizaciones similares para detectar las mejores prcticas, contenidos disponibles, o quizs aspectos que parezcan interesantes desarrollar.
Primera composicin del portal

Tomando en cuenta la primer visin del alcance del portal, el pblico objetivo, las expectativas de la organizacin y el relevamiento de sitios relacionados, puede armar una primer composicin del futuro portal y este marco de referencia le permitir enfrentarse a un relevamiento con la visin estratgica ya definida.
Ejemplo
Proyecto: Se desea disear un portal nuevo para AGESIC. Luego de realizar la primera composicin del portal, se llega a la conclusin que el portal que se desea debe: Cubrir dos dimensiones, la de informacin e interactividad. Contemplar diferentes tipos de usuarios que se espera que accedan al portal:
tomadores de decisiones que deben estar informados de la
estrategias de gobierno electrnico y de los lineamientos para los proyectos,

tcnicos de las reas TIC que desean acceder a informacin
prctica de normativa, estndares tcnicos, buenas prcticas y servicios disponibles para utilizar en sus proyectos,
empresas que desean visualizar hacia donde va el pas en
proyectos tecnolgicos y encontrar oportunidades de negocios

y ciudadanos en general que al ingresar quieren entender los
conceptos generales de gobierno electrnico y sociedad de la informacin, que es AGESIC y cules son los beneficios,
lograr posicionar los conceptos de Gobierno electrnico,
gobierno en red y difundir herramientas disponibles para uso de los organismos que son base a una plataforma de gobierno electrnico. Adems se analizaron portales de Nueva Zelanda, Argentina, Estados Unidos de organizaciones similares, pero se lleg a la conclusin que la lgica del portal que se quera con el foco en el usuario era similar al trabajo realizado por Chile compras o el portal del estado de Nuevo Len en Mxico, que aunque tienen cometidos diferentes trabajaron sobre los conceptos de usabilidad y accesibilidad que se desean incluir.
Relevamiento
Una vez que disponga de la visin de alto nivel del portal es necesario realizar un relevamiento de los contenidos que se desean incluir, las funcionalidades necesarias y de toda la normativa tcnica y legal que debe considerar.
Relevamiento de contenidos
Existen diferentes tcnicas para realizar relevamientos, puede utilizar entrevistas, formularios, encuestas en lnea, etc. Sin importar la estrategia que utilice para el relevamiento es importante tener en cuenta estos puntos: 1. Disponer de preguntas claras y concisas. Si va a realizar reuniones, preprelas adecuadamente de modo de saber de antemano qu informacin desea obtener. 2. Identificar representantes que constituirn un Grupo de trabajo integrado por las diferentes reas o sectores que puedan entender y apoyar en el relevamiento, dado que en organizaciones muy grandes quizs el equipo de direccin de proyecto no pueda alcanzar la organizacin completa en un corto tiempo. Adems los representantes de cada rea o sector conocen las necesidades del rea y pueden ajustarse a los tiempos del resto de los compaeros del rea. 3. Lograr la documentacin escrita de los mismos 4. Realizar un consolidado de toda la informacin, analizando si se encuentran dentro del alcance del proyecto y si es posible luego la gestin de esos contenidos. 5. Verificar el alcance dado en los contenidos con todas las reas.
Ver Ejemplo de formulario de relevamiento al final del captulo
Finalizado el primer relevamiento es necesario consolidar toda la informacin obtenida, pero teniendo como finalidad lograr dos documentos importantes: 1. El documento que contenga la arquitectura de la Informacin que contenga una categorizacin de los contenidos en una estructura jerrquica. Nota: Como complemento del mapa del sitio es importante identificar que contenidos generan histricos. 2. El documento de especificacin de requerimientos funcionales.
Contenidos estndar
Independientemente de su relevamiento los sitios institucionales deben tener contenidos estndar algunos como buena prctica y otros para cumplir con la ley de acceso a la informacin pblica. Es recomendable contemplar en los sitios institucionales los siguientes contenidos estndares: 1. Logo y Nombre del organismo 2. Informacin institucional: Acerca del organismo, misin, visin Cometidos del organismo en general y de cada una de sus unidades o dependencias. Marco Normativo Antecedentes Informacin de la gestin: Indicadores y metas, plan estratgico, memoria anual Estructura organizativa, autoridades, organigrama, funcionarios. Listado de funcionarios Programas de capacitacin interna Presupuesto y remuneraciones, informes de ejecucin presupuestal Convenios con otras instituciones: listado del convenios, beneficios del convenio, involucrados, documento del convenio Informacin de contactos, ubicacin del organismo y de las reas claves para el ciudadano, telfonos, y casilla de correo, as como informacin de contacto de las autoridades.
Convocatorias a concursos y resultados de los mismos. Concesiones, licitaciones, permisos y autorizaciones Informacin estadstica
3. Proyectos del organismo 4. Listado e informacin de Servicios y trmites 5. Se recomienda el desarrollo de reas de interaccin y participacin a. Buzn de sugerencias b. Foro de discusin de temas c. Mecanismos para solicitar informacin 6. Acerca del Portal a. Objetivo del portal, ultimas actualizaciones realizadas y prximos cambios que podr esperar. b. Estadsticas de acceso c. Informacin de contacto en caso de problemas con el portal 7. Aspectos Legales o Condiciones de Uso 8. Polticas que cumple: accesibilidad, privacidad, proteccin de datos, propiedad intelectual, y transparencia. 9. Se recomienda el desarrollo de una pgina de Transparencia donde coloque vnculos a toda la informacin pblica disponible para el ciudadano de manera que pueda acceder a ella fcilmente.
Especificacin de los requerimientos funcionalidades

Al plantear el alcance del proyecto es necesario considerar todas las funcionalidades que se desean incluir. Pensar esto al comienzo del proyecto le permitir conocer la dimensin del proyecto ya sea para desarrollarlo internamente como para realizar la contratacin.
Algunas de las funcionalidades deben existir sin importar el objetivo del portal, otras dependern de la herramienta seleccionada para desarrollarlo y otras del objetivo de la organizacin. A modo de ejemplo se presentan un listado de requerimientos funcionales a incluir un portal:
Funcionalidades bsicas
Buscador:
Debe incluir un buscador que permita realizar: Bsqueda sencilla - contar con una opcin bsica de buscador disponible desde cualquier pgina del portal Bsqueda avanzada que permita ubicar contenidos o personas segn diferentes campos.
Ruta de Acceso o camino de migas

Visible en todo el sitio, debe mostrar la traza de pginas que hay entre la Portada del Sitio hasta la pgina actual. Cada uno de los elementos que conforman este camino debe tener un enlace que permita el acceso a esas reas.
Mapa del sitio:

Se debe generar automticamente al publicar nuevos contenidos
Manejo de histricos de publicaciones, documentos, noticias:

Para los tipos de contenidos que tienen publicaciones habituales debe existir la posibilidad de visualizar los vigentes segn los criterios que se determinen al disear y la posibilidad de consultar el histrico organizado por los criterios adecuados al tipo de contenido.
Generador de Noticias
RSS, posibilidad de suscribirse a un servicio de noticias o boletines.
Imprimir:
Debe existir la posibilidad de imprimir contenidos en un formato de impresin.
Soporte de archivos
Se debe permitir adjuntar archivos de diferentes formatos (formato Open Office, pdf, zip, rar, jpg, gif, Microsoft office)
Foros
Los foros deben permitir definir moderador o moderadores del foro, incorporar archivos de diferentes formatos, ver las respuestas linealmente o hiladas. Permitir categorizar los foros. Permitir dentro de un mismo foro crear varios hilos de discusin. Debe existir de dar acceso a los foros por invitacin.
Ejemplo
Categora: Tcnicos 1. Foro. Diseo de Portales Lnea de discusin: Esttica de los portales Lnea de discusin: Herramientas libre de administracin de contenidos
Estadsticas de Trfico
Disponer de la informacin de las pginas visitadas, los contenidos que son descargados con mayor frecuencia y la cantidad de tiempo que los visitantes se encuentran en el sitio.
Fecha de actualizacin
Poder incorporar en los contenidos la fecha de actualizacin automticamente.
Funcionalidades de administracin y diseo

Administracin de contenidos y estructura:
Existen diferentes formas de realizar la administracin de contenidos, puede ser directamente sobre el cdigo o utilizando una herramienta que le permite realizarlo. Si la opcin que utilizar es una herramienta de administracin de contenidos esta debera permitir: Administracin de contenidos descentralizada, de manera que varios usuarios con diferentes perfiles puedan cargar los contenidos bajo su responsabilidad. Contar con rol de aprobacin de contenidos Seguridad por grupos/perfiles/usuarios y funcionalidades Administracin de men y nuevas sub-secciones Posibilidad de contar con un conjunto de herramientas nativas que permitan a generar rpidamente nuevas pginas o subsitios.
Administracin de plantillas y estilos

La herramienta que se utilice deber permitir: Realizar el diseo implementado con hoja de estilos y plantillas. Posibilidad de crear nuevos contenidos basados en una plantilla. Disponer de todos los estilos que permitan dar formato rpidamente a un contenido y mantener la calidad del diseo. Disponer de funcionalidades que permitan crear una nueva plantilla para casos excepcionales, dado que el diseo inicial debera intentar cubrir todos los casos.
Log de auditora del portal:

Sera deseable contar con un log para el portal que permita a un usuario con perfil de administrador acceder a informacin de auditora, tal como contenido publicado, autor, fecha y hora de publicacin, contenidos dados de bajas, contenidos modificados.
Requerimientos de Accesibilidad
La herramienta de Portal o el desarrollo que se realice debe disponer de los medios necesarios para permitir generar pginas Web accesibles, de acuerdo con las Web Content Accessibility Guidelines 2.0 (WCAG 2.0, recomendacin vigente a partir de diciembre 2008) y adoptada por AGESIC. Ver captulo III de Accesibilidad La solucin presentada debera cumplir como mnimo los requerimientos del nivel AA y algunas recomendaciones del nivel AAA: Ser considerado vlido el mecanismo de duplicar pginas, creando pginas especiales para usuarios con capacidades diferentes o limitadas, siempre que este proceso sea totalmente automtico y no requiera trabajo adicional. Por ejemplo, que algn componente que habitualmente se despliega utilizando tecnologa Flash se duplique en formato HTML estndar para que lo interpreten sin inconvenientes los navegadores para ciegos.
Requerimientos de usuarios y roles

Determinar el tipo de administracin, y los diferentes roles y usuarios que requerir el portal, a modo de ejemplo se detallan los siguientes: Administrador del portal, con la capacidad de realizar cambios en la estructura del portal, crear usuarios, definir perfiles y asignar permisos. Usuario que aprueba debe poder aprobar los contenidos sobre los cuales tenga permisos. Editores debe poder crear y modificar nuevos contenidos dentro de las categoras sobre las cuales tenga permisos. Con esto queremos indicar que puede haber editores en diferentes niveles. Ejemplo un usuario que puede publicar en un rea pero no en el portal pblico. Diseadores debe poder crear plantillas y nuevos estilos, tiene la capacidad de hacer modificaciones en el diseo. Usuarios del rea privada si el portal tiene reas de contenidos restringidos deber considerar la cantidad de usuarios, el tipo de permisos y las reas de contenidos que accedern.
Normativa que debe cumplir

Existe normativa que deben cumplir los organismos y que se deber reflejar en el portal que desea implementar. Es importante que desde el relevamiento sea tenida en cuenta para ir delineando las polticas: Leyes N 9.739 de 17 de diciembre de 1937 y N 17.616 de 10 de enero de 2003 sobre Derechos de Autor. Estas normas permiten proteger adecuadamente las obras fruto del intelecto humano, tales como creaciones artsticas, cientficas, literarias y programas de computacin, las creaciones multimedios (creacin original de imagen y sonido en formato digital, al cual se puede acceder mediante un programa informtico) y las bases de datos electrnicas. Ley N 18.381 de 17 de octubre de 2008 sobre Acceso a la Informacin Pblica. Que garantiza el Derecho de Acceso a la Informacin Pblica a todas las personas sin excepcin alguna y adems tiene por objeto promover la transparencia de la funcin administrativa. Ley N 18.331 de 11 de agosto de 2008 de Proteccin de Datos Personales y Accin de Habeas Data. Que garantiza una adecuada proteccin de los datos personales y establece una serie de principios que reglan el uso y tratamiento de stos, tanto en el mbito privado como pblico. Decreto 450/09 de 28 de setiembre de 2009 sobre los Principios y lineamientos estratgicos de Gobierno Electrnico.
Ver captulo IV- Normativa
Seleccin de las herramientas y opciones para la implementacin

Una vez terminado el relevamiento, con el documento de especificaciones armado y el mapa de sitio deseado, se est en condiciones de planificar el desarrollo del portal o la contratacin de una empresa que le permita llevarlo a cabo. En cualquiera de los casos es importante tener presente algunos puntos importantes para la seleccin de opciones para la implementacin, es recomendable disponer de una herramienta que le permita administrar sus contenidos, generar nuevos y disponer un esquema de usuarios, permisos y roles que le permitan establecer procesos de edicin, aprobacin y publicacin como mnimo. Existen herramientas propietarias y libres (Plone, Drupal, Liferay, Joomla, etc.) que pueden ser utilizadas a tales fines. Sin importar cual elija verifique que la seleccionada realmente le permitir cumplir con los requerimientos de contenidos, los requerimientos funcionales, los requerimientos de diseo y los de administracin del portal, adems de tener un respaldo de una comunidad de prctica que le permita evacuar dudas. Un detalle no menor al seleccionar la herramienta es la facilidad de migracin ante cambios de versiones y el ajuste de las funcionalidades cada vez que cambia la versin.
Plan de contenidos
Una vez que se realiz el relevamiento y dispone de la primera versin del mapa del sitio tiene un panorama claro del volumen de documentos y contenidos a publicar. Estos contenidos pueden encontrarse en una versin anterior del portal y habr que considerar su migracin, o en archivos de la organizacin, con diferentes formatos, escritos por diferentes personas e incluso en papel. Dado que el proceso de diseo y maquetacin es un proceso que llevar unos cuantos das, en paralelo al resto de las actividades es conveniente disear un plan para el desarrollo de contenidos en el que se establezca tres grandes actividades: Desarrollar las pautas generales que utilizar el organismo para los contenidos publicados en la web pensando en el pblico objetivo, el tipo de contenido y el plan de comunicaciones si existiese. Dentro de las mismas se debe considerar: pautas de redaccin, uso de nombres oficiales, unificacin de terminologa en temas especficos,
generacin de glosarios para usuarios no-tcnicos, pautas para nombres de archivos, etc. Ver como redactar en la web en el Captulo II - Usabilidad. Realizar un cronograma de desarrollo de contenidos que incluya los siguientes puntos:
Tipo de contenido Explicacin del Contenido a desarrollar Responsable de desarrollo o de procurar el contenido Plazo para el cual debe estar disponible
Consideraciones a tener en cuenta: Al desarrollar el plan de contenidos encontrar que existen textos, imgenes, material multimedia, etc. Este es el momento de considerar: Imgenes: Verifique si dispone de un banco de imgenes, si utilizar imgenes de otras fuentes verifique que no infringe normas de derecho de autor (Ver captulo IV. Propiedad Intelectual), si necesita colocar imgenes nuevas si debe pedir al equipo de diseo que las cree.
En Internet dispone de bancos de imgenes libres que puede utilizar:
Ejemplo
A continuacin mostramos dos ejemplos de bancos de imgenes gratuitos que puede encontrar en Internet http://www.sxc.hu/
http://www.bluevertigo.com.ar/bluevertigo.htm
Textos: Si utiliza texto de otras fuentes, es importante identificar las fuentes y controlar que no viola ninguna norma de propiedad intelectual. Si coloca a disposicin textos propios verifique si no debe incluir alguna clausula de privacidad o de licenciamiento del mismo (Ver captulo IV Normativa). Otra cosa que es importante es determinar que formato publicar los archivos adjuntos. Si los documentos son de distribucin, es decir, el usuario no necesita modificarlos, de recomienda utilizar el formato PDF, que es un estndar internacional de ISO especfico para este fin. Si son editables se recomienda siempre incluir en la distribucin una versin bajo el estndar ODF. En ambos casos deber tener en cuenta que los documentos deben ser accesibles. Multimedia: Si dispone de material multimedia para publicar verifique la pautas de accesibilidad y la necesidad de generar las transcripciones o material alternativo que permita acceder a este tipo de contenidos. (Ver captulo III. Accesibilidad) Formar un equipo de trabajo responsable de validar los contenidos independientemente del formato.
El proceso de preparar los contenidos podra ser un proceso paralelo, eso depender del plazo que disponga para su proyecto. Deber asegurarse que los mismos estn disponibles para la fecha en que comience la capacitacin y la herramienta est instalada y configurada pronta para comenzar con la carga. Algo importante al disponer de los contenidos y es la falla en muchos sitios web es la calidad de los contenidos y el plan de comunicacin. Verique que realmente cada tema a publicar est tratado como el organismo desea publicarlo y difundirlo.
Diseo del Portal

Para disear el portal deber pasar por las siguientes actividades: diseo de bocetos, aplicacin de esttica a los bocetos y maquetacin. En cada una de estas actividades deber tener en cuenta: 1. Para el diseo de bocetos: el nivel de desarrollo del portal deseado, el pblico objetivo, el plan de comunicacin y sobre todo criterios de usabilidad. 2. Para el diseo de la esttica: la imagen corporativa (si existiese) y sino la imagen que se desea proyectar. 3. Para la maquetacin: los requerimientos funcionales y los requerimientos de accesibilidad.
Diseo de bocetos
Fuente: Artculo Web para humanos de la pgina http://webparahumanos.wordpress.com/2009/03/03/diseno-de-prototiposwireframes-para-proyecto-nuevo-portal-web-unicauca/. Fecha de Acceso: 24/11/2009
Sin importar si el equipo del organismo desarrolla el portal o se contrata una empresa el primer paso es realizar los bocetos o wireframes. Esta es una tcnica que consiste en desarrollar dibujos en papel o con cualquier software de diseo grfico, en los cuales se describe cmo se veran las pginas individualmente, pero sin incluir los aspectos grficos de detalle. Le permite clarificar los conceptos y los requerimientos que hasta ahora tena en forma terica. En estos dibujos se trata de especificar y mostrar claramente en donde estar ubicado cada uno de los elementos que componen una determinada pgina, tales como el encabezado, el buscador, los sistemas de navegacin, el contenido, el pie de pgina, entre otros. Los wireframes describen el contenido y la arquitectura de informacin que ser incluida. Al pensarlos debe mantener el foco en cul es su pblico objetivo y que preguntas desea que su portal sea capaz de contestar, as como que servicios desea colocar a disposicin. Esta informacin fue la que relev inicialmente. Un wireframes grafica bsicamente: Elementos de navegacin: mens, accesos directos e hipervnculos. Elementos de informacin: contenidos de texto e imgenes. Elementos de interaccin: herramientas o funcionalidades que el usuario puede realizar. Elementos de apoyo: tems de ayuda y orientacin, como mapas de navegacin o preguntas frecuentes Elementos promocionales: espacio dedicado a banners publicitarios o a destacados. La ubicacin y el tamao relativo de cada uno de estos elementos respecto al resto. Los wireframes son creados comnmente para las pginas ms importantes del sitio tales como las pginas de inicio, las principales categoras de las pginas y las interfaces de bsqueda - y otras aplicaciones importantes. Tambin son usados para describir plantillas que se aplican para muchas pginas de forma consistente, tales como las pginas de contenido del sitio. Es importante al hacer este ejercicio detectar cuantas plantillas necesitar crear e intentar estandarizarlas, de manera que se transformen en herramientas que luego permitan crecer en contenidos sin necesidad de disear nuevas.
Al disear los wireframes o bocetos deber tener en cuenta conceptos de usabilidad indispensables para lograr un sitio que cumpla con los objetivos fijados inicialmente.
Ver Captulo II Usabilidad.
Ejemplo
Ejemplo de wireframes En la figura que colocamos a continuacin encontrar un boceto en blanco y negro, donde se visualiza la arquitectura de la informacin de la portada. Por ahora no debe preocuparse de la esttica del mismo, solamente de la interaccin, arquitectura de la informacin y usabilidad del sitio.
Fuente: http://www.guindo.com/casos/terra.htm
A continuacin se muestra el boceto con la esttica incluida.
Fuente http://www.guindo.com/casos/terra.htm
Al finalizar los bocetos deber tener definido un conjunto de plantillas que relejarn la estructura completa del portal, detallando en particular la arquitectura de la informacin y los elementos ms relevantes de usabilidad. Los bocetos debern incluir una justificacin de cada decisin tomada, de manera de poder utilizarla en el momento de presentar su propuesta y realizar la validacin.
Diseo de la esttica
Una vez que tenemos los bocetos aprobados, el prximo pasos es aplicarle el diseo y la esttica al boceto.
Fuente: http://www.d26.com.mx/btm/web-design-desarrollo-web.jpg
Esto deber ser realizado por un equipo de diseo y tendrn en cuenta la imagen corporativa si est definida si existe. Es importante al disear tener en cuenta las pautas de accesibilidad. Ver captulo III Accesibilidad. Es conveniente desarrollar al menos dos diseos de manera que al validar existan opciones de seleccin. Dentro del diseo de la esttica, se deben incluir: Tema del portal Combinacin de colores Fuente a utilizar (recuerde utilizar las fuentes del sistema) Estilos de ttulos y subttulos Estilos de prrafos Seleccin de imgenes y disposicin de las imgenes
Algo muy til es prever con el equipo de diseo el disponer de un banco de imgenes ya creadas de manera que al cargar los contenidos se pueda ir directamente a ellas sin correr el riesgo de violar leyes de propiedad intelectual.
Maquetacin e implementacin
Maquetar un sitio web es armar la estructura bsica de plantillas sobre el cual se implementar todo el sitio. Al maquetar deber separar la presentacin del contenido. Se recomienda no utilizar tablas para maquetar o disear un sitio web, ya que de esa forma se mezcla la presentacin y el contenido. Lo mejor es utilizar CSS y HTML/XHTML y respetar los estndares establecidos por la W3C ya que facilita la accesibilidad, la correcta visualizacin de los contenidos por diferentes navegadores y diferentes medios. Maquetar usando CSS y utilizar estndares le permitir: 1. Separar la forma del contenido usando CSS y HTML. 2. Reducir el trfico en el servidor, ya que las pginas se reducen en tamao y los navegadores guardan la hoja de estilos en cach. 3. Reducir el tiempo de carga de las pginas 4. Reducir el tiempo de mantenimiento cuando se deben cambiar los estilos 5. Cambiar fcilmente la esttica completa o parcial de un sitio cambiando las hojas de estilos. 6. Que sus pginas queden mejor posicionadas en los buscadores, ya que semnticamente son correctas. En la implementacin se sugiere seguir las siguientes recomendaciones: 1. Utilizar cdigo de despliegue HTML 4.01 estndar (no mejorado para un visualizador en especial) o XHTML 1.0 validado ante el W3C. 2. Optimice el peso de las imgenes para que sean livianas, se recomienda .jpeg para las fotos. 3. Se recomienda usar un solo directorio para almacenar las imgenes repetidas, tales como los conos y otros elementos grficos que son utilizados en diferentes pginas del sitio. Esto posibilitar aprovechar la
funcin de cach del programa visualizador para mejorar el rendimiento de las pginas. 4. Usar el atributo ALT (texto alterno) en imgenes en el cdigo HTML: ste se desplegar antes que las imgenes y, de esta forma, facilitar la comprensin del contenido a los usuarios que tendrn la opcin de verlas o avanzar directo al sitio. 5. Indicar el formato y el peso de los archivos cuando se ofrecen elementos grficos o audiovisuales para ser bajados a la computadora personal del usuario (especialmente en Video, Audio, Flash u otros) se recomienda indicar el peso con el objeto de ofrecer informacin til para efectuar la operacin. Por ejemplo descargar video (mpeg 4.2 MB) 6. Seguir con todas las pautas de accesibilidad. Ver Captulo III Accesibilidad.
Validacin y Puesta en produccin

Despus de realizada la estructura bsica del sitio y la carga de los contenidos bsicos debe realizar diferentes validaciones, para las cuales les proponemos algunas herramientas que pueden facilitar y automatizar las tareas: Probar el sitio con las versiones para diferentes sistemas operativos de diversos visualizadores de pginas (browsers): Siempre hacerlo como mnimo con dos versiones de Microsoft Internet Explorer y con la ms actual de Mozilla Firefox. Es recomendable tambin visualizarlo con Opera y Safari, este ltimo preferiblemente sobre sistema operativo Mac. Para validar la compatibilidad con diferentes versiones de Internet Explorer puede utilizar: http://www.my-debugbar.com/wiki/IETester/HomePage Probar el sitio en un monitor monocromo: Tambin se puede validar haciendo una impresin blanco y negro o configurando la aplicacin del usuario para que no muestre los colores y verificar as que toda la informacin es accesible.
Para verla en blanco y negro puede usar la Firefox Accessibility Extensin (Firefox) o la Web Accessibility Toolbar (Internet Explorer y Opera). Probar el sitio con un lector de pantalla para personas ciegas para comprobar que todo el contenido es accesible. Ejemplo de herramientas que puede usar: Un lector de pantalla como JAWS (descargar demo gratuita de Jaw 9.0) o FireVox (lector de pantalla que se instala como extensin de Firefox). Descarga de JAWS: http://www.freedomscientific.com/downloads/jaws/jaws-downloads.asp Descarga gratuita de FireVox: http://firevox.clcworld.net/ aDesigner - Es una herramienta local gratuita que permite simular cmo "ve" una pgina dos tipos de usuarios diferentes: una persona ciega con un lector de pantalla o una persona con visin reducida. Adems permite evaluar la accesibilidad de documentos ODF, animaciones Flash o de una aplicacin de escritorio. Validar como se visualiza en diferentes resoluciones: Para eso hay una herramienta online en ingls Screen Size Tester que permite revisar una web a distintas resoluciones. http://www.anybrowser.com/ScreenSizeTest.html Validar las hojas de estilos: Usando el servicio de validacin de W3C, al cual accede mediante el siguiente vnculo: http://jigsaw.w3.org/css-validator/ Validar los estndares HTML: Mediante la herramienta proporcionada por W3C http://validator.w3.org/. Una vez introducido y validado tu cdigo; mostrar los errores y su ubicacin con lo que podr iniciar la correccin para llevar su pgina a un estndar. Validar los enlaces rotos: Para eso utilice el validador de W3C: http://validator.w3.org/checklink.
Validar el tiempo de carga de las pginas: Existe una herramienta online en ingls que calcula el tiempo de carga de las pginas y cada uno de sus objetos. Puede acceder a ella a travs de http://tools.pingdom.com/ Los sitios web deben tener un peso mximo permitido por pgina que no supere una cantidad razonable de kilobytes (kb) para que puedan visualizarse con cualquier tipo de conexin. Un usuario no esperar ms de: 5 segundos para que aparezca algo visible en la pantalla. 10 segundos para que aparezca algo legible en la pantalla. Muy importante: Evitar en todos los casos las pginas que no despliegan ningn contenido hasta que no descargan todos los archivos. Verificar que apenas se comienza a descargar el primer archivo, el navegador comienza a desplegar la pgina. Este es el comportamiento default de todos los navegadores, por lo que cualquier alteracin es debida al cdigo del propio sitio. Validar los contenidos: La forma de redaccin y la ortografa. Validar seguridad: Las actividades que se pueden realizar para hacer las pruebas de seguridad son diversas y se orientan a varios mbitos, como se describe a continuacin. Los temas a tratar son los siguientes: manejo de DNS, proteccin de estructura interna del Sitio Web, proteccin contra robots, manejo de privacidad, canales seguros, mecanismos de control de acceso, proteccin de programas, hosting vs. sitio propio y roles mnimos a asegurar. Ver captulo 5. Seguridad
Gestin de los contenidos

La puesta en produccin de un portal, determina el inicio de nuevos retos: Conformacin de un equipo responsable de los contenidos La actualizacin de contenidos La administracin del portal Los procedimientos de cambios o ampliaciones
Actualizacin de los Contenidos

El sitio web ser exitoso si ofrece la informacin esperada accesible, actualizada y confiable. Esto implicar el tener un conjunto de procedimientos bien estructurados y la implementacin de un grupo de trabajo con diferentes roles: editores, responsables de aprobacin y administradores. Es importante concientizar a la organizacin de la importancia de generar informacin que alimente el portal, y la responsabilidad de aquellos que publican. Para facilitar la publicacin se sugiere que exista: un mecanismo o flujo de trabajo para la dentro de cada rea y un responsable general del sitio. Dentro de ese procedimiento se debe identificar quien genera contenidos, quien tiene el rol de editor por su capacidad para escribir en la web, quien tiene el rol de verificar y aprobar el documento y quien tiene el rol de publicacin final. Estos roles pueden caer en una o varias personas pero tenga en cuenta la conveniencia que al menos una persona edite los contenidos y otro corrija y apruebe. Manual para el editor con pautas de cmo redactar en la web y como utilizar la terminologa del organismo en forma correcta. Manual de uso de estilos donde se especifique como se deben usar los diferentes estilos y plantillas creadas. Esto permitir que cualquiera de los editores de contenido mantengan la calidad del sitio. Manual de pautas del portal donde especifique las pautas a seguir referente a uso de imgenes, nombres de archivos, formatos de archivos permitidos, plantillas de documentos que debe usar, como hacer versiones pblicas de documentos, pautas de propiedad intelectual adoptadas por el organismo y como seguir las polticas adoptadas.
Cada contenido del portal deber tener la fecha de actualizacin, de manera que los usuarios puedan detectar rpidamente la evolucin de los contenidos.
Gestin de los documentos publicados

Para cada documento publicado en el sitio de Internet se debera indicar origen, autor, y fecha de publicacin. Estos atributos de la informacin constituyen claros indicadores de la calidad del servicio. La actualizacin del sitio de Internet debe guardar correspondencia con la informacin que genera el organismo (por ejemplo: los ltimos datos estadsticos). En los casos de descarga de documentos hay que indicar claramente su tamao y ponga especial cuidado en el nombre de los archivos que estos sean lo suficientemente descriptivos. La gestin de datos histricos debe evaluarse en cada sitio, segn los contenidos y las necesidades. En los casos en que se consideren de utilidad deberan reubicarse en un lugar de guarda de informacin histrica al que se pueda acceder mediante motores de bsqueda generales con opciones de bsquedas avanzadas.
Evolucin del portal

Un sitio eficaz debera evolucionar conforme con el crecimiento y el grado de interaccin que establezca con su audiencia. Dicha evolucin puede incluir: La actualizacin e incorporacin de datos. El rediseo parcial o total. La implementacin de nuevas funcionalidades y/o servicios en lnea. El rea que coordina el sitio de Internet debera: elaborar las pautas y/o mtodos para que se mantenga actualizada la informacin por las distintas reas de la organizacin, coordinando dicha tarea; proponer el rediseo parcial o total del mismo, teniendo en cuenta la innovacin tecnolgica; incentivar y colaborar con las distintas reas de la organizacin en la implementacin de nuevos servicios.
Auditora
Resulta indispensable realizar una auditora o evaluacin constante del sitio, a efectos de asegurar la accesibilidad, la navegabilidad, la seguridad, etc., de modo de implementar acciones correctivas en lapsos cortos. Los responsables deberan articular procedimientos evaluadores de los usuarios del sitio, por ejemplo, el desarrollo de encuestas y otras formas de inclusin de la opinin de los destinatarios, en los que se contemple: Quin lo ha visitado. Cunto tiempo ha estado. A qu pginas accedi. Cmo lo encontr. La auditora del sitio tambin debera incluir la verificacin de: La eliminacin de enlaces corruptos y accesos deshabilitados. La calidad de impresin de las pginas en distintos tipos de impresoras. El cumplimiento de la poltica de seguridad del sitio. El procesamiento y estandarizacin de los mensajes de error. El anlisis de trfico y/o archivo de logs. Estadsticas de acceso a pginas. Accesibilidad de los contenidos nuevos
Fuente: portal del estado de Nuevo Len http://www.nl.gob.mx
Lista de revisin
Tener un listado que le permita realizar una revisin de todos los aspectos considerados en la planificacin de sus proyectos puede resultar til a la hora de trabajar.
Actividad Inicio del Proyecto Tarea Conformar equipo de direccin de proyecto Desarrollar documento1. Primera composicin del portal Nivel de desarrollo del portal del organismo decidido Pblico objetivo determinado Informacin y productos a difundir definidos Lista de sitios de referencia seleccionados Conformar equipo de trabajo con representantes de la organizacin Armar plan del proyecto Relevamiento Disear Formulario de relevamiento Realizar relevamiento de contenidos y funcionalidades en cada una de las reas Desarrollar documento2. Consolidado de contenidos realizados y validados Desarrollar documento3. Especificacin de requerimientos Desarrollar documento4. Primer versin del mapa del sitio Validar todos los documentos Seleccin de herramientas y recursos Desarrollar documentos para la contratacin de una empresa armados Seleccionar Herramienta a utilizar Estado
Actividad Plan de Contenidos
Tarea Realizar cronograma de desarrollo de contenidos Realizar reunin con representantes de las reas para explicar el plan de contenidos Conformar un equipo responsable de control de calidad de contenidos Redactar gua para desarrollar los contenidos con especificaciones de pautas de redaccin y especificaciones de forma Seleccionar banco de imgenes Disponer de todos los contenidos armados Desarrollar los documentos de polticas a incluir en el portal
Estado
Diseo del portal
Disear de bocetos o wireframes Validar de los bocetos Aplicar esttica a los bocetos Validar la esttica y seleccionar una opcin Maquetar sitio web Implementar maquetacin Cargar de contenidos
Validacin
Validar en diferentes browser Validar en B/N Validar con un lector de pantalla para personas no videntes Validar con diferentes resoluciones Validar las hojas de estilo
Actividad
Tarea Validar los estndares HTML Validar enlaces rotos Validar tiempo de carga de las pginas Validar contenidos Validar seguridad
Estado
Capacitar
Plan de capacitacin desarrollado Capacitar Administradores del portal Capacitar editores de contenidos Desarrollar manuales de usuario y guas para editores
Puesta en produccin
Validacin final Puesta en produccin
Gestin de contenidos
Desarrollo de un procedimiento de publicacin para la organizacin Desarrollo del manual para el editor, con pautas de redaccin y pautas a seguir en el portal. Desarrollo del manual de uso de estilos y plantillas Difusin de todos los documentos
Evolucin del portal
Procedimiento de cambios Elaboracin de una estrategia de crecimiento del portal
Auditora
Realizar auditora de accesos al portal Realizar auditora de cumplimiento de pautas de propiedad intelectual, de accesibilidad, de estilos, de redaccin Revisin de enlaces rotos
Formulario de relevamiento
A continuacin presentamos un ejemplo de formulario de relevamiento
PROYECTO XX Diseo del Portal FORMULARIO DE REQUERIMIENTOS

El objetivo del presente formulario es poder registrar los requerimientos a nivel funcional, de contenidos y de servicios que tiene cada una de las reas dentro de este proyecto. La suma de los documentos de requerimientos presentados por cada rea, ms los identificados por el equipo responsable del proyecto, sern la base para la definicin de la estrategia a seguir en la estructuracin de los contenidos del portal, a nivel de diseo, de comunicacin y determinacin de las prioridades durante cada fase.
1. Informacin del rea

Complete informacin que identifique el rea y los contactos
Identificacin del rea: Representante del rea: Fecha de Presentacin:
Complete informacin que permita mostrar la visin de su rea en un portal
Indique la lista de contenidos que su rea tiene publicados en el portal actual?
2. Portal
Cul es la Visin desde su rea del Portal que debera disponer?
Describa brevemente la idea es explicarnos que tipo de portal visualizan desde el rea que les sera de utilidad para posicionar la organizacin y que necesitan los usuarios que acceden a la informacin generada desde su rea.
Visin General: Pblico objetivo
Qu contenidos sern generados por su rea para publicar en el Portal?

Visualizamos cada una de las reas como generadores de contenidos y servicios. Necesitamos identificar, cada uno de ellos de manera de disear una estructura de portal lo suficientemente flexible para soportar el crecimiento. Es importante conocer su plan a corto, mediano y largo plazo, de manera de poder planificar el crecimiento del sitio.
Categorice la informacin. Especifique una clasificacin tentativa
Descripcin del contenido Describa brevemente el contenido Genera histrico
Servicios que desea proporcionar

Indique que servicios sern responsabilidad del rea que no fueron contemplados en las preguntas anteriores. Ejemplo: Debe permitir el acceso al sistema de consultas de expedientes, o debe permitir el acceso a la intranet de la empresa.
Categorice el tipo de servicio. Especifique una clasificacin tentativa
Descripcin del servicio Describa brevemente el servicio que desea integrar
Requerimientos funcionales que necesita

Indique que otros requerimientos se presentan en el rea que no fueron contemplados en las preguntas anteriores. Ejemplo: Foro de discusin, rea de chat, gestor de documentos, etc.
Categorice el tipo de requerimiento. Especifique una clasificacin si es posible
Descripcin
Noticias Su rea generar noticias?

Indique que tipo de noticias genera y con qu periodicidad si le es posible.
Captulo II
Usabilidad
Captulo II Usabilidad | 49
La usabilidad es como el oxgeno: nunca la notas... hasta que te falta. Annimo
Qu es la Usabilidad
Tal vez no haya mejor forma de explicar qu es la Usabilidad que la "Tetera para Masoquistas", del artista francs Jacques Carelman. All estn presentes todas las funciones, cumple con todos los requisitos, pero es muy difcil sino imposible concebir su uso normal sin inconvenientes. La Usabilidad es la disciplina que se encarga de construir ese intangible que hace precisamente que las distintas funciones puedan ser utilizadas por los usuarios "sin inconvenientes", con la menor dificultad posible. Desde un punto de vista ms formal, cuando un individuo se enfrenta a una herramienta informtica, sea sta una aplicacin de escritorio o un sitio Web, tiene que lidiar con problemas que provienen de dos orgenes distintos: los que son inherentes a la tarea que est desempeando y los que son inherentes al uso de la propia herramienta y por tanto ajenos a la tarea. La situacin ideal es aquella donde no existen dificultades y problemas inherentes a la herramienta, donde la herramienta informtica es "invisible". La Usabilidad es la disciplina que tiene como objetivo reducir al mnimo las dificultades de uso inherentes a una herramienta informtica, analizando la forma en que los usuarios utilizan las aplicaciones y sitios Web con el objetivo de detectar los problemas que se les presentan y proponer alternativas para solucionarlos, de modo de que la interaccin de dichos usuarios con las aplicaciones y sitios Web sea sencilla, agradable y productiva.
50 | Captulo II Usabilidad
La mejor interfaz es la que no existe

A diferencia de otras disciplinas de diseo, el trabajo en Usabilidad debe ser invisible para el pblico en general. La Usabilidad no genera satisfaccin hasta que no se la experimenta y en general se obtienen los mejores resultados a mediano y largo plazo. Esta condicin deriva de algunos atributos caractersticos de la Usabilidad. Todas las interfaces se pueden usar: hasta la versin ms complicada construida por el cerebro ms retorcido puede ser utilizada. La Usabilidad es un atributo de calidad. Los problemas de Usabilidad nunca son catastrficos: a diferencia de otras reas tcnicas donde una falta grave como una falla en la base de datos o un corte de energa invalidan el uso del sistema completo, los problemas de Usabilidad, incluso los ms graves, no generan interrupciones generales y abruptas. Por el contrario, generan un xodo silencioso de usuarios insatisfechos, que descartan el uso del sitio sin demasiada estridencia. No hay una solucin puntual: las soluciones a los problemas de Usabilidad siempre tienen fuertes componentes metodolgicos y se producen por acumulacin. En la mayora de las situaciones no es posible encontrar dos o tres problemas cuya solucin desate el nudo principal. Por el contrario, la tarea de detectar los problemas y proponer soluciones debe ser acompaada de un trabajo metdico de incorporacin de la Usabilidad en los procesos habituales, como nica forma de garantizar la facilidad de uso a largo plazo.
El objetivo de la Usabilidad es entonces, desde cierto punto de vista, hacer menos interfaz y no lo contrario. El destino final es construir aplicaciones donde el 100% de los esfuerzos del usuario estn destinados a la tarea y esto implica 0% de interfaz. Es muy fcil encontrar sitios donde el diseo de la interfaz intenta ser la vedette de la pantalla, interponindose fuertemente entre el usuario y sus objetivos. Distrayendo y complicando atrae para s esfuerzos que deberan ser volcados en la propia tarea. Comprender la paradoja que trae consigo hacer mnimo el esfuerzo que implica la interfaz es "el desafo" de quienes se deciden a trabajar en Usabilidad.
Beneficios
Los sitios Web fciles de usar producen un conjunto de beneficios tanto en la etapa inicial de puesta en marcha del proyecto como cuando el emprendimiento est en rgimen de funcionamiento normal. Usuarios ms satisfechos: la satisfaccin de los usuarios es un resultado directo de las posibilidades que tengan de conseguir sus objetivos con el mnimo esfuerzo posible. Usuarios ms fieles: la facilidad de uso produce una utilizacin mayor tanto en frecuencia como en amplitud de funcionalidades utilizadas. Menor costo de soporte: una aplicacin ms fcil de usar genera menos problemas a los usuarios y por tanto estos consultan menos, reduciendo las necesidades de soporte y ayuda. Menor costo de mantenimiento: los problemas de Usabilidad surgen inmediatamente a la luz a travs de las llamadas a soporte y quejas de los usuarios, lo que genera un ciclo permanente de modificaciones. Sin dudas es mejor hacer las aplicaciones ms usables al momento de construirlas.
Los beneficios de la Usabilidad son amplios y tienen impacto tanto desde el punto de vista de la imagen del sitio como desde el punto de vista econmico. Sin embargo, es importante tener en cuenta que los beneficios llegan una vez que el proyecto est en el aire, por lo que la nica garanta para generar sitios Web usables es tomar en cuenta deliberadamente la Usabilidad desde el primer da del proyecto. Una observacin relevante es que desarrollar software usable no es a priori ni ms caro ni ms barato que desarrollar software no-usable. La cantidad de sitios con abultado presupuesto, alto esfuerzo de diseo grfico e interfaces de psima Usabilidad as lo prueban. Si por el mismo costo se puede desarrollar un sitio mediocre o un gran sitio que mejore significativamente el retorno sobre la inversin, la eleccin parece obvia. Por qu entonces hay tantas carencias de Usabilidad? Tal vez esta afirmacin irnica del Bill Gates, fundador y presidente de Microsoft pueda aportar una pista:
"Los proveedores de software estn intentando hacer sus aplicativos ms 'amigables con el usuario'... Su mejor estrategia hasta ahora ha sido tomar los viejos folletos y agregarles un sello con las palabras 'amigable con el usuario' en la tapa."
Detrs de la irona se esconden dos conceptos de gran relevancia. En primer lugar, si se quieren obtener los beneficios de las interfaces fciles de usar, entonces es imprescindible incorporar la disciplina al comienzo del proceso y no luego de que est en marcha. Menos an cuando todo est terminado. El segundo es que la Usabilidad es un intangible elusivo, que provee beneficios a mediano y largo plazo, por lo que frente a la disyuntiva de elegir entre dos aplicativos o sitios antes de conocerlos en profundidad, los usuarios (y muchas veces las propias organizaciones creadoras de los sitios), no cuentan con las herramientas para distinguir aquel que es fcil de usar del que no lo es.
Elementos de la interfaz de usuario

Cuando en la mesa de un restaurant el mozo nos sirve un atractivo y exquisito plato, somos testigos de la culminacin de un proceso que abarca una larga sucesin de actividades y decisiones, algunas de las cuales ocurrieron hace mucho tiempo. As mismo, cuando un usuario se sienta frente a la pantalla de su computadora y navega con rapidez y satisfaccin por un sitio Web, est interactuando con el resultado una larga sucesin de actividades y decisiones que llevaron al sitio a ser como es y no de otra forma. Para mejorar la Usabilidad de un sitio es imprescindible hacer explcita ante quienes lo construyen la lista que conformar la sucesin de tareas y decisiones de modo de poder ponderar, priorizar y asignar los recursos adecuados a cada una de ellas. Para eso, tomaremos como base el modelo propuesto por Jesse James Garrett en el libro Los elementos de la Experiencia de Usuario1. El modelo divide los elementos de la interfaz en 5 grandes grupos, que describiremos partiendo de los cimientos conceptuales y subiendo hacia las capas ms concretas, donde se efecta realmente la interaccin en la prctica.
Figura 2 - Elementos de la interfaz de usuario
The elements of User Experience Jesse James Garret Peachit Press, USA. Octubre de 2002.
Objetivos
- Podra decirme, por favor, qu camino debo seguir? - Eso depende de dnde quieres llegar- dijo el gato. - No me importa- dijo Alicia. - Entonces no importa el camino que sigas- dijo el gato. Lewis Carroll "Las Aventuras de Alicia en el Pas de las Maravillas"
La cantidad de tiempo, esfuerzo y dinero, y por sobre todas las cosas, los dolores de cabeza que se ahorraran si tomramos en cuenta este pequeo dilogo son inconmensurables. De ah la grandeza de Lewis Carroll. Pero el hecho de que la lgica sea obvia y las consecuencias sean implacables no hace cierto per se que los sitios conozcan sus objetivos de alto nivel y a partir de ellos puedan tomar las decisiones que les permitan construirlos. Antes de comenzar el proceso de construccin de un sitio Web deben quedar bien definidas las respuestas a algunas preguntas simples pero bsicas. Y si el sitio est en el aire y an no pas por esta etapa, hgalo lo antes posible, si fuera posible ahora mismo. Por qu necesitamos un sitio? La respuesta puede ser tan trivial como "Porque todos tienen uno" o tan compleja como "Porque necesitamos bajar un 20% la espera en el call center". Y vale cualquier opcin entre ellas. Pero es mandatorio entender el rol que el sitio juega en la organizacin: comunicar, difundir, ahorrar costos, vender, tramitar. Todas son vlidas, hay que definir con claridad cules son las que estamos persiguiendo. Para quin es el sitio? A todos nos gustara que nuestro sitio que fuera visitado por millones de personas todos los das. Pero esa no es la ms comn de las situaciones. Saber a quin le hablamos va a determinar cmo debemos hablarle, qu tipo de material le interesa y cmo debe ser la interfaz. Est el ejemplo obvio de jvenes / adultos mayores, pero hay muchas situaciones relevantes y no tan triviales.
Qu debe suceder para que estemos satisfechos? Tener muchas visitas, que se hagan muchas descargas, que se reciban muchas consultas, salir en la prensa. Cmo me doy cuenta de que me fue bien? Si se cumplen todas las anteriores, lo que implica que sucedieron muchas otras cosas buenas, sin dudas nos encontramos ante un xito. Si no se cumple ninguna, el fracaso est en puerta. Pero otra vez los extremos no son la situacin habitual. Tal vez el equipo de trabajo considere ms relevantes otras preguntas. Tal vez para las que proponemos tengan matices. Lo relevante es plantearlas y dar respuestas sencillas, claras y comprensibles para el equipo de trabajo y para toda la organizacin. Un ejemplo de objetivos: "Construiremos un sitio para comunicar los derechos y obligaciones de los ciudadanos con respecto a la nueva ley de Seguro de Paro. El sitio apunta a los trabajadores y a los empleadores. Aspiramos que el pblico encuentre las preguntas frecuentes ms sencillas en el sitio y que eso se refleje en un nmero mnimo de llamados al call center."
Alcance
El alcance de un sitio Web est determinado por los objetivos que un visitante va a poder cumplir en l. Tiene una relacin directa con los objetivos, pero mientras los objetivos reflejan el punto de vista de la organizacin, el alcance tiene el punto de vista de los usuarios del sitio. Por ejemplo, en un sitio que tenga como objetivo "aumentar las ventas de celulares" el alcance podra estar definido como "Encontrar toda la informacin para poder comprar un celular". Se trata del mismo problema visto desde pticas distintas: la primera es la de la organizacin, la segunda la del usuario. Fijar el alcance produce un quiebre significativo en el proceso de definicin de un sitio Web, porque implica traducir los objetivos de la organizacin en los objetivos de los visitantes, clientes, ciudadanos o como se prefiera denominar al pblico objetivo, permitiendo construir el sitio de afuera hacia adentro.
Personajes Objetivos - Escenarios

Una metodologa de uso extendido y probada eficacia para definir el alcance es la que se denomina Personajes - Objetivos - Escenarios, introducida por Alan Cooper en el libro Presos de la Tecnologa de 1999.2 La experiencia muestra que las dos prcticas ms comunes, tanto el concepto ambiguo y abstracto de usuario, como la caracterizacin por rangos utilizada en el marketing (sexo masculino, entre 20 y 60 aos, ingresos medios, etc.) no contribuyen de forma efectiva a la definicin del alcance en el escenario del diseo vinculado a productos tecnolgicos, de los cuales la creacin de un sitio o aplicacin Web es un exponente. Por su parte, Personajes Objetivos Escenarios ha mostrado ser una poderosa herramienta de diseo. Se trata de una metodologa de fcil aplicacin que permite sustituir la idea genrica de usuario por una caracterizacin de quin utilizar el sitio, por qu lo utilizar y en qu situaciones lo har.
Personajes
El punto de partida de la metodologa de Personajes - Objetivos - Escenarios es la identificacin clara de quines visitarn nuestro sitio Web. Para ello la propuesta es definir las caractersticas del perfil de los futuros usuarios, casi una caricatura del universo de visitantes. Un personaje debe permitir al equipo de trabajo entender qu buscan los visitantes del sitio, qu cosas requieren y cules no. Algunas caractersticas de la definicin de un buen personaje son las siguientes: Debe tener nombre. Mejor an un apodo. Un nombre o apodo bien elegido puede decir todo sobre los visitantes del sitio. Sea cual sea el proyecto el personaje "Doa Justina" nos hace pensar en un alcance totalmente distinto que "Dark Nerd". Dar una descripcin de sus caractersticas, gustos, capacidades y costumbres relevantes para el proyecto. Describir al personaje refuerza la idea del nombre o apodo, lo "pinta" y permite que cada uno de nosotros se lo imagine. Mientras Doa Justina hace los mandados con la bolsa de la feria, tiene en el aparador un portarretrato de cada uno de los nietos y juega al solitario de Windows, porque no se anima a
Presos de la Tecnologa. Por qu los productos tecnolgicos nos vuelven locos y cmo recuperar la cordura Alan Cooper - Addison Wesley Longman, USA. Marzo de 2001. (La primera edicin en Ingls corresponde a 1999)
probar con otro juego, Dark Nerd jams se levanta antes de las 13 horas, vive de crear blogs para publicar avisos de Google y vender cosas usadas en Mercado Libre. Su mquina tiene una cantidad inconmensurable de memoria, 2 monitores enormes y al menos 4 sistemas operativos instalados. Deben ser inventados. Tal vez uno pueda inspirarse en una persona del mundo real. Pensamos en Doa Justina porque es parecida a una ta y Dark Nerd se basa en un sobrino. Pero los personajes tienen que ser ficticios, porque de otro modo se corre el riesgo de que pierdan su valor como herramienta de diseo y el sitio termine siendo una aplicacin "a medida" para un individuo. Para sentirse cmodo con los personajes, bsqueles una foto y cree fichas con sus nombres y caractersticas. Los personajes son una herramienta de diseo simple y poderosa, que a un costo mnimo sern una ayuda invaluable a lo largo de todo el proyecto. Hacerlos perdurables en una ficha con una imagen y la descripcin permitir hacerlos conocer y traerlos al ruedo cuando sea necesario.
Doa Justina
Es una abuela activa. Pasa mucho tiempo con los nietos y tambin con "las chiquilinas", sus compaeras de toda la vida. La computadora no es su amiga, pero las fotos de su nieta en Sdney hicieron que maneje el correo electrnico y la navegacin por Internet de una forma primitiva pero "suficiente para m" como le gusta decir. Tambin juega mucho al solitario y al tetris.
Objetivos
Navegar en Internet es una tarea, o una herramienta, casi nunca un objetivo. Las personas actan cuando tienen una razn imperativa para hacerlo. Cuando exista un conjunto de causas que se constituyan en una razn poderosa, nuestro usuario actuar, utilizando las funciones que pusimos a su alcance en el sitio. Si bien para alcanzar los objetivos hay que desarrollar tareas, no hay que confundir uno con otro. Los objetivos tienden a ser pocos, a permanecer
estables en el tiempo. Las tareas tienden a ser muchas y a cambiar con una fuerte dependencia de la tecnologa del momento. El objetivo es el fin, las tareas el medio. Por ejemplo, mientras que comunicarnos es un objetivo ancestral, que permanece incambiado desde el surgimiento mismo del Homo Sapiens, las tareas que implica la comunicacin han tomado las formas variadas y cambiantes a lo largo de la historia, dependiendo de los medios y tecnologas disponibles en cada momento. Cuando Doa Justina se sienta a la computadora para ver una foto de su nieta, lejos de querer leer el mail o abrir un archivo, est movida por el poderoso y ancestral objetivo de la comunicacin familiar. Tener mucha funcionalidad, lo que se traduce en permitir desarrollar una gran cantidad de tareas, no necesariamente tiene relacin directa con los objetivos de los usuarios. Si usted busca un destornillador determinado, cuantas ms herramientas tenga la caja de herramientas, ms difcil ser la bsqueda. Y si las herramientas son slo destornilladores, peor an. La funcionalidad crea herramientas. El diseo crea experiencias. Los usuarios se sentirn ms satisfechos cuando encuentren exactamente la cantidad necesaria, ni una ms, ni una menos, de funciones que los ayuden a alcanzar sus objetivos. Focalizarse en el objetivo de sus personajes, entender este objetivo y concentrase en l, le permitir abordar con creatividad y libertad el anlisis de las tareas y la funcionalidad que las implementa. Podr libremente eliminarlas, crear nuevas, o cambiarlas completamente. En la Web el problema de encontrar el objetivo de nuestros visitantes es muy importante. No hay forma de llevar el sitio al usuario, es ste quien tiene que decidir venir a nuestro sitio y para ello tiene que tener un motivo, una razn imperiosa para actuar. Despus que lleg tenemos que ayudarlo a cumplir su objetivo rpidamente, si fuera posible en el mismo instante en el que llega. Eso es garanta de usuarios satisfechos, que vuelven una y otra vez.
Doa Justina
Es una abuela activa. Pasa mucho tiempo con los nietos y tambin con "las chiquilinas", sus compaeras de toda la vida. La computadora no es su amiga, pero las fotos de su nieta en Sdney hicieron que maneje el correo electrnico y la navegacin por Internet de una forma primitiva pero "suficiente para m" como le gusta decir. Tambin juega mucho al solitario y al tetris. Objetivos: Justina se mud y cambi el lugar de cobro descentralizado de su jubilacin. Se acerca la fecha de cobro y quiere saber si se mantiene la fecha y hora habitual o vari con el cambio.
Escenarios
Para entender cmo harn los usuarios para cumplir con sus objetivos utilizando nuestro sitio, es necesario un elemento ms: intentar describir cmo es el entorno y la actitud con que lo utilizarn. No es lo mismo una persona apurada que una que tiene mucho tiempo. No es lo mismo alguien que se deleita con lo que hace que alguien que lo sufre. Los escenarios son la herramienta para enfrentar este desafo. Un escenario no es otra cosa que la descripcin de la situacin y el contexto en el que se desarrolla la interaccin del usuario con el sitio. En la relacin de un usuario con un sitio pueden en general detectarse varios escenarios, que reflejan una serie de contextos o situaciones en que los distintos pblicos interactan para conseguir sus objetivos.
Escenarios de uso diario

En todo sitio Web existen 2 o 3 escenarios que representan las interacciones bsicas que realizar el usuario con frecuencia. Se trata de apenas 2 o 3 escenarios. Inclusive muchas veces un solo escenario es suficiente. Casi, casi nunca son 10. Esos son los escenarios de uso diario. Independientemente del tamao del sitio Web y el universo de funciones incluya, el 80% del tiempo del usuario se desarrollar en esos 2 o 3 escenarios. Es en los escenarios de uso diario en los que los usuarios alcanzarn sus objetivos. Es en la interaccin que estos escenarios construyen que lo usuarios
sern felices o infelices al usar nuestro sitio: la satisfaccin no viene de forma homognea de todas y cada una de las funciones. Un pequeo detalle errado en un escenario de uso diario terminar por irritar al usuario ms tolerante, como la gota que orada la piedra. Por ejemplo, en un sitio de correo electrnico "EL" escenario central y que ocupa casi todo el tiempo es el de "Revisar el correo", que incluye las herramientas para ver la bandeja de entrada, leer correos y escribir correos. El resto de las decenas de herramientas que ofrece un sitio de correo electrnico moderno tienen un uso tan espordico que no alcanzan siquiera a un papel secundario. La distribucin homognea del esfuerzo de diseo es un error tan frecuente como nocivo. Concntrese en encontrar sus personajes, identificar sus objetivos y dedique el 80% de los recursos de diseo a la interaccin del escenario (o de los escenarios) de uso diario. Tambin all est escondido el 80% del xito.
Escenarios de uso espordico o de nica vez.

Tienen las mismas caractersticas que los de uso diario: son el lugar donde los usuarios cumplen sus objetivos. La diferencia radica en que los usuarios los utilizan con una frecuencia muy baja, y eso tiene una consecuencia de vital importancia para la interfaz y la facilidad de uso: no hay curva de aprendizaje o esta tiene una incidencia mnima. Los escenarios de uso espordico o de nica vez son los reyes de la Web y son parte vital de la mayora de los sitios, a los que los usuarios entrarn una sola vez a cumplir un objetivo puntual. Mientras que en los escenarios de uso diario los usuarios aprenden con el uso y aplican lo que aprendieron de una visita a la siguiente, el uso espordico o de nica vez implica que cada ocasin en la que el usuario se enfrenta al sitio comienza de cero. Esto hace que cobren relevancia algunas premisas de diseo: Directo y sin sutileza: la interfaz debe ser directa, con interacciones simples, sin ambigedades, evitando cualquier elemento que implique aprendizaje o descubrimiento Estndar: el usuario debe poder aplicar al mximo todo lo que conoce del dominio de la tarea y de su experiencia en otros sitios Web. Una tarea por vez: los usuarios acceden a cumplir un objetivo, en general muy simple y bien definido. La interfaz debe estar 100% orientada a este objetivo.
Sin personalizacin: La ecuacin de la personalizacin es trabajar hoy para ahorrar maana. Es una ecuacin que provoca solo prdidas para quien no va a retornar al sitio.
Detectar y comprender al definir la estrategia de diseo que los usuarios darn un uso de nica vez a nuestra sitio Web resulta determinante para maximizar el valor que obtendrn del sitio y con ello el retorno de la inversin. Estadsticas tpicas para un sitio Web
Desde el punto de vista de la organizacin que crea el sitio, la informacin publicada puede ser vista como vital y en general es manejada en el da a da de los participantes del equipo, por lo que no es difcil sobrevalorar la importancia que el sitio y sus contenidos tienen en realidad para los usuarios. Sin embargo la situacin ms frecuente, segn las estadsticas, es que los visitantes que retornan al sitio constituyen un entorno del 15% o menos del total de visitantes: la mayora aplastante no solo son primerizos, tampoco tienen intencin o necesidad de regresar. Esto implica que en la mayora de los casos si queremos disear sitios usables, debemos tener en mente que los escenarios de ms alto trfico sern utilizados por los usuarios por nica vez, y que esto implica que cuando llegan al sitio no tendrn otro bagaje de conocimientos que el que les proporcion su experiencia en los otros sitios de Internet que visitaron antes que el nuestro.
Escenarios de uso necesario

Los escenarios de uso necesario abarcan las interacciones imprescindibles para poder usar el sistema, que con raras excepciones son de uso poco frecuente o nulo. Si bien el diseo de esas interacciones debe ser cuidado, si usted enamor al personaje de su sistema o sitio Web en los escenarios de uso diario, entender que es imprescindible desarrollar una determinada tarea una vez cada tanto, y estar dispuesto a una interaccin no tan agradable. Sumado a ello, el hecho de que sean poco frecuentes har muy difcil que el usuario recuerde lo aprendido de una interaccin a la siguiente. Como corolario, ya hemos gastado en los escenarios de uso diario el 80% del esfuerzo de diseo, por lo que nos queda solo un 20%. Lo ms importante es que no son los usuarios los que cumplen sus objetivos en los escenarios de uso necesario, sino los programadores del sitio, que se ven limitados por la arquitectura, el modelo de desarrollo, la tecnologa disponible o cualquier otro impedimento tcnico que los obliga justificadamente a hacer trabajar a los usuarios para que el sistema funcione. Mientras que el objetivo de los escenarios de uso diario debe ser fascinar al cliente, los de uso necesario deben tener como objetivo que ste realice su tarea sin frustrase. Si puede, elimnelos sin piedad sustituyndolos por valores por omisin y programacin defensiva, que prev que los usuarios no tienen inters en configurar determinados detalles. En todo caso, preocpese de que no queden en medio del camino, separando a los usuarios del cumplimiento de sus objetivos.
Doa Justina
Es una abuela activa. Pasa mucho tiempo con los nietos y tambin con "las chiquilinas", sus compaeras de toda la vida. La computadora no es su amiga, pero las fotos de su nieta en Sydney hicieron que maneje el correo electrnico y la navegacin por Internet de una forma primitiva pero "suficiente para m" como le gusta decir. Tambin juega mucho al solitario y al Tetris. Objetivos: Justina se mud y cambi el lugar de cobro descentralizado de su jubilacin. Se acerca la fecha de cobro y quiere saber si se mantiene la fecha y hora habitual o vari con el cambio. Escenario (uso espordico): Mientras lee el correo electrnico, Justina se anima a probar si puede averiguar la fecha de cobro en Internet, una posibilidad que la publicidad en televisin est anunciando hace unos das. Lo hace muy despacio y con muchas dudas, casi con miedo.
Alcance, contenido y herramientas

Ya sea utilizando la metodologa de Personajes - Objetivos Escenarios, ya sea de la forma que considere ms conveniente, definir el alcance implica conocer los objetivos y expectativas de los usuarios que visitarn el sitio desde su propio punto de vista. Es a partir de este conocimiento que podremos determinar qu contenidos y herramientas debern estar en el sitio. No al revs. Dicho en otras palabras: si el alcance es la traduccin de los objetivos de la organizacin al lenguaje del usuario, la traduccin a la visin y forma de ver el problema del usuario, lo razonable es que el sitio se asiente fuertemente en el alcance. Es por ello que slo una vez definido el alcance estaremos en condiciones de listar qu cosas podr hacer y leer el usuario en nuestro sitio.
Arquitectura de la informacin
Con los objetivos del sitio en su lugar, con el alcance definido a partir de estos objetivos, estamos en condiciones de comenzar a trabajar en el contenido del sitio. La arquitectura de la informacin es la herramienta que nos permitir definir y ordenar el contenido de modo de hacer ms fcil para el usuario encontrarlo y utilizarlo. Podemos pensar en las siguientes tareas para la definicin de la arquitectura de la informacin de un sitio: Definicin de Categoras: Se trata de un conjunto de conceptos de alto nivel que permiten dividir en grupos todos los documentos y contenidos, a partir de una concepcin de la relacin entre los grandes temas que abarca el sitio. Una buena definicin de categoras debe cumplir: Las categoras son mutuamente excluyentes. Tienen una jerarqua equivalente. Por ejemplo "televisores" pertenece a "electrodomsticos", por lo que incluir a ambos como categoras no parece una buena idea. Abarcan todo el universo de contenido.
Las categoras pueden dividirse en subcategoras y as sucesivamente formando una estructura de rbol o piramidal que recibe el nombre de taxonoma. Televisores es entonces una subcategora de electrodomsticos. Categorizar los documentos: Indicar a qu categora o categoras pertenece cada documento. Dependiendo de la definicin de las categoras implcitas en la taxonoma, un documento puede ser ubicado en ms de una categora: "El Capital" es un libro clsico, de economa o de poltica? En general, con universos de contenido amplios, resulta muy difcil construir una categorizacin exacta que ubique a cada documento en una sola categora y cuando se consigue hacerlo el valor de la categorizacin es mnimo, como por ejemplo con el orden alfabtico de los ttulos de las pginas. Un documento puede ser categorizado de mltiples formas: al ubicarlo en la estructura del sitio, agregndole los nombres de las categoras como "palabras clave" o agregando un conjunto de datos invisibles (o no) que determinen a qu categora pertenece. Esta ltima tcnica es la que se conoce como metadatos.
Recuperacin de la informacin - Navegacin: la arquitectura de la informacin permite definir cmo se va a navegar el sitio. La transicin de taxonoma a sistema de menes no es mecnica, pero hay una fuerte relacin entre la organizacin de categoras y la organizacin de menes. Dentro de la navegacin podemos distinguir: Navegacin Global: muestra la divisin ms general de la informacin del sitio y se corresponde con los niveles de primer orden de la taxonoma. En general se plasma en un "men principal" que est presente en todas o la mayora de las pginas del sitio. En una tienda de electrodomsticos la navegacin global podra incluir: "lnea blanca", "audio", "TV", etc. Navegacin Local: muestra la jerarqua de categoras de una "rama" del rbol que tiene como origen cualquiera de las categoras de la navegacin global (sub-taxonoma). En la tienda, para la opcin "TV" de la navegacin global se podran incluir "De Plasma", "LCD", "Tradicionales (CRT)", etc. Navegacin Contextual: permite navegar desde el contenido que se est desplegando en la pantalla a contenidos relacionados. Incluye desde el scroll (acceder a la porcin del contenido que no est en este instante en la pantalla) hasta las listas de temas relacionados, mapas temticos, etc.
Recuperacin de la informacin - Bsquedas: Otra forma de recuperar la informacin almacenada es a travs de los sistemas de bsqueda. Se trata de un tema muy amplio que abarca desde soluciones casi triviales hasta las fronteras del conocimiento informtico actual. En general podemos tener como criterio vlido que todo sitio Web debe proveer un mecanismo de bsqueda y que los mecanismos de bajo costo son en general aceptables cuando la coleccin de documentos es pequea. Cuando la coleccin crece y el universo se hace ms grande y por tanto ms complejo (varias decenas de miles de documentos o ms), empieza a ser razonable pensar en sistemas de bsqueda adaptados especialmente a la arquitectura definida, que permitan expandir o contraer las bsquedas a partir del contenido de la taxonoma. De esta forma, por ejemplo, cuando se busca una clave se incluyen adems los resultados de la bsqueda de los sinnimos de esa clave en la taxonoma (expandir una bsqueda) o cuando se busca "latitud Pars", la palabra "latitud" indica que se trata de resultados geogrficos, por lo que se excluyen los contenidos que incluyen Paris en referencia al prncipe troyano cuyas peripecias se narran en la Ilada y que en la taxonoma pertenecen a la rama "historia" (contraer una bsqueda).
Contar con una taxonoma permite adems modificar de acuerdo a las necesidades el ranking de los resultados, para hacer por ejemplo que "Tabar Vzquez" no sea apenas una clave de bsqueda ms.
Modelo de Interaccin
Nos vamos acercando a la interfaz de usuario propiamente dicha, a lo que el usuario ver finalmente en la pantalla. Sobre la arquitectura de la informacin que definimos, es necesario ahora concebir el modelo de interaccin con el que el sitio interactuar con los usuarios. Un modelo de interaccin supone un conjunto de funcionalidades bsicas o primitivas sobre las que se construyen las funcionalidades ms complejas. As sobre la primitiva "vnculo" se construyen las funcionalidades hipertexto, men y botn, o sobre la primitiva "mouse over" se construyen las funcionalidades tooltip (ayuda que aparece al detener el mouse sobre un elemento de la interfaz), men desplegable y elemento colapsable.
El Modelo Mental
El libro de Donald A. Norman "El diseo de todos los das", publicado en 1988, signific un punto de inflexin en la conceptualizacin de las interfaces no solo de los programas de computadora sino de todos los productos de tecnologa en general. Uno de los puntos claves fue la introduccin de los conceptos bsicos para entender la relacin entre el individuo que utiliza el equipamiento y la implementacin de la solucin, diferenciando claramente lo que el individuo conceptualiza en su cerebro a partir de lo que percibe, el Modelo Mental, de lo que el tcnico implement en realidad, el Modelo de Implementacin. En medio de ellos, y haciendo posible el relacionamiento entre ambos, que no es otra cosa que el uso del producto tecnolgico, se encuentra el Modelo de Interaccin. Entender que los usuarios construyen un modelo mental para utilizar los productos tecnolgicos y fundamentalmente que este modelo es sustancialmente diferente de la implementacin real fue un aporte sustancial en la construccin de una teora ms slida en la que basar la construccin de interfaces.
Podemos resumir los conceptos de la siguiente forma: Modelo de Implementacin: Es el modelo que sigui el programador para construir el sitio Web y que tiene como prioridad que la funcionalidad se cumpla de una forma eficaz, segura y con un consumo mnimo de recursos informticos. (Design model en la terminologa de Donald A. Norman). Modelo Mental: Es la visin del problema que el usuario tiene en su cabeza cuando interacta con el sitio producto del conocimiento previo sobre el dominio de la tarea, de la interaccin con otros sitios y de la experiencia acumulada en la interaccin con el sitio. (User's Model en la terminologa de Donald A. Norman). Modelo de Interaccin: Es el modelo que soporta la relacin entre el usuario y el sitio, compuesto por los elementos visibles del sitio as como por las posibilidades de interaccin que el sitio propone. Cumple el rol de enganche o bisagra entre el Modelo de Implementacin y el Modelo Mental. (System Image en la terminologa de Donald A. Norman).
A partir del trabajo de Norman, Alan Cooper expuso un esquema que ejemplifica con claridad el mandato de diseo: el Modelo de Interaccin debe parecerse lo ms posible al modelo mental del usuario. Esto tiene dos consecuencias fundamentales: la primera es que en el caso del software debe alejarse del modelo de implementacin, que poco tiene que ver con la forma en que la gente comn concibe la solucin a los problemas y la segunda es que no son los tcnicos informticos quienes deben crear el Modelo de Interaccin, sino que se trata de una disciplina distinta, que Cooper llam Diseo de la Interaccin
Del Modelo mental al Modelo de Interaccin 3 No solamente para que un sitio sea fcil de usar el Modelo de Interaccin, es decir la forma en que el sitio se presenta hacia el exterior, debe acercarse lo ms posible al Modelo Mental con el que el usuario arriba a utilizarlo. El recproco tambin es vlido. Cada vez que la interaccin se aparta del Modelo Mental y se acerca al Modelo de Implementacin el sitio se torna ms difcil, ya que el usuario se aparta de la consecucin de sus objetivos al invertir su tiempo en la comprensin de las complejidades de la tecnologa que da soporte al sitio. Un ejemplo tpico de este problema es la navegacin calcada o copiada del sistema de archivos subyacente, donde el texto de cada vnculo es el nombre del archivo. Si bien la implementacin es universal en los exploradores de los sistemas de archivos, es una interfaz muy pobre comparada con la potencia y posibilidades de la interfaz Web. En definitiva cuanto ms se acerca la interfaz del sitio al Modelo Mental del usuario, ms fcil de usar resultar el sitio.
El Modelo de Interaccin no es la Interfaz

Una confusin muy comn es la de Modelo de Interaccin e Interfaz. Tal vez sea ms fcil entenderlo con un ejemplo: todos los blogs generados en blogspot.com tienen el mismo modelo de interaccin, sin embargo tienen una interfaz distinta. Mientras que el modelo de interaccin define qu funcionalidad estar disponible y qu elementos o primitivas de interaccin son las que la implementan, la interfaz por su parte define cmo se representan estos elementos en la pantalla, qu aspecto tienen y cmo se plasma la imagen de la organizacin en el sitio. Naturalmente que un nico modelo de interaccin
3
El trabajo de Alan Cooper se basa en la idea expuesta por Donald A. Noman en el libro "The design of Everyday Things". The design of everyday things - Donald A. Norman, Pgina 16 - Basic Books, Nueva York, USA -1988 About Face 2.0 - Alan Cooper, Pgina 22 - Wiley Publishing Inc. Indianapolis, USA - 2003
produce en general interfaces ms parecidas entre s que aquellas que tienen modelos de interaccin radicalmente distintos. La relacin entre el Modelo de Interaccin y la interfaz es muy fuerte y las virtudes y defectos de uno influirn fuertemente en el otro. Pero de ello no se deduce que no sea necesario y provechoso trabajar por ellos de forma independiente.
Caractersticas de un Modelo de Interaccin

Sin nimo de ser exhaustivos, proponemos algunas caractersticas relevantes para la definicin de un Modelo de Interaccin de calidad: Cuantas menos primitivas, mejor. No es sencillo encontrar primitivas potentes y flexibles, pero ese es el objetivo. Un buen Modelo de Interaccin debe estar apoyado en un pequeo conjunto de primitivas que permitan cubrir un abanico muy grande de requerimientos funcionales. Por ejemplo, el triunvirato Copiar/Cortar/Pegar constituye una primitiva de una simplicidad y potencia asombrosas. Parece hasta contradictorio que un concepto tan elemental haya alcanzado un uso tan universal. Eso la ha hecho sobrevivir sin cambio alguno durante ms de 25 aos y estar presente en prcticamente todas las interfaces de usuario. Recordable como un refrn: Segn escribe Alan Cooper en el libro "About Face"4, las buenas primitivas son como refranes: o se entienden sin explicaciones, o hay que explicarlas una nica vez, ya que jams se olvidan. Un modelo de interaccin debe estar construido en base a este tipo de primitivas. Hoy es prcticamente imposible encontrar un usuario que no conozca el funcionamiento del mouse, pero este dispositivo no existi por siempre y la documentacin al respecto de las primeras experimentaciones muestra que no todos los usuarios entendan sin ayuda como funcionaba. Todas son contundentes en sealar que ningn usuario requera una segunda explicacin. Genrico y abarcativo: el Modelo de Interaccin debe funcionar sino en todos, en prcticamente todos los contextos que el sitio Web lo requiera. Las excepciones deben ser pocas (realmente excepcionales) y muy justificadas.
El Modelo de Interaccin es invisible a los ojos del usuario. La definicin de un modelo de interaccin para todo el sitio Web genera una interfaz ms estable, uniforme y fcil de usar. Y cuando est bien definido, dura en el tiempo y permite resolver con poco esfuerzo un abanico muy importante de problemas.
4 About Face: The essentials of User Interface Design - Alan Cooper - John Wiley & Sons, USA. Agosto de 1995.
Interfaz
La interfaz es desde el punto de vista estrictamente tcnico el conjunto de puntos de contacto del usuario con el sitio a travs de la computadora, e incluye todo lo que el sitio emite o muestra (salida o "output") y todo lo que el sitio recibe (entrada o "input"). Dicho de otra forma, la interfaz es lo que se muestra en la pantalla, se emite por los parlantes, se imprime en la impresora, etc., sumado al conjunto de acciones que el usuario puede realizar utilizando el mouse y el teclado. Es la parte sensible (visible, tocable, audible) de la interaccin. La interfaz contiene las imgenes, los tipos de letra, los colores y en general todos los elementos grficos. Tambin pertenece a la interfaz el puntero del ratn, el llenado de campos y cada una de las soluciones para la captura de datos.
El factor emocional en el diseo

Todas las disciplinas de diseo, y el diseo de sitios Web no es una excepcin, plantean la discusin sobre la relacin entre forma y funcin. Es importante sealar al respecto de este tema algunas consideraciones relevantes desde el punto de vista de la Usabilidad.
La esttica y los componentes emocionales que genera influyen en la Usabilidad

Hay evidencia cientfica acerca de que el factor emocional influye positiva o negativamente en la facilidad de uso de un sitio Web. En particular, el libro El Diseo Emocional5 del Psiquiatra Donald A. Norman cubre en detalle la problemtica y el trabajo de investigacin que fundamenta esta afirmacin. El problema radica en que la Usabilidad no es un elemento de calidad inherente nicamente al sitio Web, o en forma ms general al software, sino que es una
El diseo emocional. Por qu nos gustan o no los objetos cotidianos. Donald A. Norman Ediciones Paidos Iberica, Espaa. Mayo de 2005.
cualidad atribuible a la interaccin del usuario con el sitio Web, de donde deriva que el individuo que interacta con el sitio forma parte de la ecuacin. Desde este punto de vista la predisposicin del usuario hacia el sitio influir significativamente en la actitud con que ste encare la interaccin. Ya sea con un espritu exploratorio y tolerante, con una actitud muy crtica y severa o con las infinitas posibilidades y perfiles que quedan en medio de stas. Por ejemplo, un portal de Rock Pesado que no tenga una imagen grfica oscura y estridente provocar automticamente prevencin en los usuarios que lo visitan, generando una navegacin ms orientada a validar que se trata de un sitio "apcrifo" que a descartar los prejuicios que la imagen genera, lo que degradar sensiblemente la capacidad del usuario de conseguir sus objetivos.
No elegir: lindo y fcil de usar

La discusin entre forma y contenido tiene numerosos contendientes que priorizan uno sobre el otro, en distintas relaciones y niveles de equilibrio o desequilibrio. Desde las corrientes minimalistas hasta los defensores a ultranza de la moda como un valor per se, hay numerosas escuelas y discursos. Desde el punto de vista de la Usabilidad podemos afirmar sin temor a equivocarnos que uno no sustituye a otro en ningn caso: un gran sitio debe ser estticamente exquisito y terriblemente fcil de usar. A la vez. El hecho de que los aspectos estticos sean visibles los hace centro de la discusin, pero ello no eleva su importancia relativa, inclusive a pesar de que la Usabilidad por su propia naturaleza contribuya en muchos casos a este tipo de enfoque con sus atributos de intangible, invisible y efectos de mediano plazo. El diseador de la interaccin del sitio debe tener una preocupacin simultnea por ambos, en una relacin en la que se potencien mutuamente.
La interfaz es compartida con el navegador

Una particularidad relevante en la interfaz de un sitio Web es que el navegador que lo contiene y despliega forma parte integral de la interfaz del propio sitio. Desde el punto de vista del usuario no hay una barrera clara y definida entre el sitio y el navegador: es un todo continuo y as espera que se comporte sin necesidad de discernir si la barra de scroll pertenece a uno o al otro o cul de ellos emiti los mensajes de error. Este concepto va an ms all porque los usuarios no tienen una idea acabada de dnde empieza y termina el sitio. Se trata de una consecuencia que deriva lgica y naturalmente de la forma en que se navega, cambiando
permanentemente entre distintos sitios, del lmite endeble y borroso entre lo que hace el navegador y lo que hace el propio sitio y del contenido de las propias pginas, en las que es omnipresente el collage de contenido de numerosos sitios distintos: una pgina de resultados de Google es en definitiva la suma de partes tomadas de 10 sitios distintos que tienen relacin con la clave de bsqueda ingresada. Los ejemplos de fronteras borrosas entre el navegador y el sitio son mltiples: los campos de bsqueda integrados al navegador, los feeds, las barras de navegador que completan automticamente algunos campos y los sistemas para recordar contraseas, por citar solo algunos. Segn distintos estudios, el navegador6 se lleva aproximadamente el 35% de los clics, con la barra de scroll y el botn atrs como los mximos receptores de estos clic. Esto se hace notorio en los sitios que incluyen una segunda barra de scroll al interior de la pgina y mucho ms an cuando esta no es una barra del propio navegador, sino una generada por programacin del propio sitio, algo tpico de los sitios hechos en Flash. La Usabilidad se reduce radicalmente, con usuarios que no consiguen pasar el contenido (hacer scroll) y ni siquiera llegan a percibir por qu. La interfaz tiene entonces la pesada responsabilidad de ser la parte del sitio que el usuario percibe, debe plasmar todas las definiciones tomadas en los niveles anteriores, en las que se bas su concepcin. Y debe adems hacerlo en equilibrio con el navegador que la contiene.
La interfaz es para que se luzcan... los usuarios

Un error comn que se debe evitar en el diseo de sitios Web y portales es el diseo orientado a la promocin del diseador. El sitio se transforma en una obra de arte o un objeto de exhibicin que se muestra totalmente desprendida de su valor en el cumplimiento del objetivo para el que fue concebido.
Ver al respecto Designing Web Usability - Jakob Nielsen - Peachpit Press, USA. Diciembre de 1999
Esto ocurre en muchos casos porque quienes juegan el rol de sponsors no son habitualmente quienes utilizarn el sitio en el da a da y la evaluacin constituye apenas unos minutos en los que el diseador muestra su trabajo l mismo, navegando en un ambiente totalmente controlado. El diseo del sitio, desde el primer hasta el ltimo elemento, tanto desde el punto de vista de la Usabilidad como desde el de la esttica debe estar totalmente consagrado a que los usuarios cumplan sus objetivos. El xito del sitio es siempre indirecto: quienes lo hacen habrn conseguido un logro digno de destacar si sus usuarios cumplen sus objetivos al utilizarlo con un alto grado de satisfaccin en la tarea.
Miro, leo, pienso: tres niveles de interaccin

De todas las estrategias y herramientas para maximizar la Usabilidad, tal vez sta sea la ms fcil de comprender y utilizar. Su sencillez no va en detrimento de su potencia, sino todo lo contrario, su aplicacin tiene un impacto significativo en los resultados. Fue presentada por primera vez a la comunidad de profesionales de Usabilidad en el nmero de lanzamiento de la revista Faz, en noviembre de 2007. Se puede acceder al artculo original en http://www.revistafaz.org/numero1/revistafaz_low.pdf
Tres niveles de interaccin

Para crear pginas y sitios Web fciles de comprender y usar es importante pasar al otro lado del mostrador y entender cmo los visitantes de esos sitios interactan con ellos. De alguna manera, maximizar la facilidad de uso es sinnimo de optimizar el sitio para que las estrategias de interaccin de los visitantes funcionen lo mejor posible. A los efectos de pensar la interfaz, puede concebirse la interaccin de los visitantes con un sitio Web en tres niveles: mirar, leer y pensar. Cada uno de ellos requiere un nivel de atencin particular, un esfuerzo consciente particular y retorna al visitante un nivel de resultados particular. La interaccin con un sitio Web se desarrolla simultneamente en los tres niveles, stos se combinan e interactan permanentemente entre s y el visitante obtiene su experiencia como un todo, sin necesidad de tener conciencia alguna sobre qu nivel fue el que le aport qu dato.
Miro y entiendo
El nivel ms bsico de interaccin es el que podemos llamar "Miro y entiendo". Se trata de un nivel de interaccin semiconsciente o inconsciente, donde el visitante requiere de esfuerzo casi nulo para hacerse de informacin y conocimiento. Cuando un visitante se enfrenta a un sitio Web, lo hace con un bagaje de experiencias y aprendizajes previamente adquiridos que intentar utilizar para reconocer patrones, relaciones causa-efecto y en general todo aquello que le
ayude a generar un contexto que le permita manejarse de forma ptima dentro del sitio. En este bagaje de experiencias tiene una particularsima importancia la experiencia previa de navegacin en la Web.
Agrupacin Visual Los patrones a reconocer son en general tan sencillos como poderosa es su influencia en nuestra comprensin. La figura muestra uno de los ms primitivos y elementales, pero a la vez ms tiles: la agrupacin visual. A pesar de que los cuadrados no tienen contenido alguno, es obvio y natural que los dos de arriba y los dos de abajo tienen alguna relacin entre s ms fuerte que la que tienen los de la izquierda o los de la derecha. Si el diseo tuvo en cuenta el nivel "Miro y entiendo" entonces la agrupacin visual, los efectos cromticos, los espacios, la ubicacin, los tamaos, entre otros elementos, permiten al visitante comprender mltiples aspectos de la pgina que ve sin esfuerzo alguno y de forma prcticamente inmediata, aumentando enormemente la facilidad de uso.
La intuicin
Es dentro del nivel miro y entiendo que debe ser tomada en cuenta la intuicin. A diferencia de la creencia popular de que la intuicin es una especie de sexto sentido con el que se nace, la intuicin no es ms que una serie de patrones simples y elementales con los que el individuo ha interactuado una cantidad suficiente de veces como para que su reconocimiento e interpretacin sea semiconsciente o inconsciente. La respiracin es una actividad cuyo control puede ser consciente o inconsciente. Habitualmente prestamos poca o nula atencin a la respiracin, a pesar de lo cual respiramos sin inconvenientes. Cuando es necesario podemos controlar la respiracin de modo de realizar la actividad de alguna forma particular, como por ejemplo cuando el mdico nos indica "Respire hondo...". Las actividades de reconocimiento de patrones que componen la intuicin
funcionan exactamente igual, con la diferencia de que no son innatas sino aprendidas. Cuando ando en bicicleta, no tengo que pensar ni en pedalear, ni en balancear el cuerpo, ni en cmo mover la direccin para mantener el equilibrio. Cuando quiero puedo pasar estas actividades al terreno de lo consciente y realizarlas de alguna forma particular, como cuando me enfrento a una pendiente de gran ngulo. El funcionamiento se torna tan natural que tendemos a pensar que nacimos con l, pero no por ello deja de ser aprendido. La consecuencia prctica de la intuicin para el diseo es que quien quiera aprovecharla debe buscar los patrones que los individuos han aprendido a lo largo de su vida y reproducirlos, dejando la mayor cantidad de pistas posibles de este hecho. En la Web, esto se traduce en el respeto de los estndares tanto explcitos como de facto. Este mecanismo reproduce y refuerza an ms los patrones. Veamos un ejemplo sencillo: el ttulo de un artculo, una nota o una pgina Web es grande y est arriba, alineado a la izquierda o eventualmente centrado. Ese patrn ha sido visto por todos los humanos lectores de lenguas que se escriben de izquierda a derecha miles y miles de veces y su reconocimiento es instantneo a pesar de que no nacieron con l. Cuando un visitante llega a una pgina cualquiera de un sitio Web desde un buscador, lo primero que hace es tratar de buscar pistas que le indiquen si acert en su seleccin en la lista de resultados del buscador y el ttulo de la pgina es la preferida. Si en la parte superior de la pgina hay un texto prominente: es el ttulo! Es una relacin intuitiva, de tipo miro y entiendo. De lo contrario, el visitante tendr que pasar a otros niveles de interaccin para detectar cul es el ttulo de la pgina, en caso de que realmente tenga un ttulo.
Leo y entiendo
Leo y entiendo constituye el nivel siguiente de interaccin, despus de miro y entiendo. Se trata de un nivel ms potente, pero que requiere ms esfuerzo. Tal como su nombre lo indica, este modo de interaccin requiere que el visitante del sitio lea el contenido de las etiquetas y textos. La particularidad est en el hecho de que no necesita nada ms que el texto que se lee para comprender cabalmente el sentido del mismo. No necesita conocer a la empresa, ni la Pgina de Inicio, ni las especificaciones de un producto: leo y entiendo es lo que podramos llamar lectura autoexplicativa. Mientras que un link como "Catlogo de Productos" cae sin duda dentro de la categora leo y entiendo, un link como "Soporte" cae en general fuera de sta, dado que tengo que tener en mi poder ms informacin para saber si se trata de soporte para los productos o de soporte para el uso del sitio en el que estoy navegando, por
ejemplo. El ubicuo "Haga clic aqu" es siempre una oportunidad de mejora, ya que en ningn caso cae dentro de la categora leo y entiendo. El nivel leo y entiendo no es absoluto, sino que depende del contexto en el que me encuentro y del conocimiento previo de los visitantes de mi sitio. Es un error frecuente asumir que los visitantes tienen ms conocimiento del contexto del que realmente tienen, en particular con respecto al propio sitio. El paso del tiempo, la llegada al sitio desde un buscador y el desconocimiento total y absoluto de la organizacin que publica el sitio, entre otros, son todos factores que se suman para hacer que los visitantes se sientan como un latino que lleg hace una hora a China y tiene que pedir comida en un restaurante de un suburbio de Pekn: apenas unas raras pistas le permiten distinguir las carnes de los vegetales y lo que se mueve de lo que est quieto: los nombres, los olores y los colores no le dicen nada.
Pienso y entiendo
El nivel superior, y al que acudimos para entender cualquier problema que est a nuestro alcance es el de pienso y entiendo: ya sea para recordar algo ledo anteriormente o para hacer referencia a conocimientos adquiridos en otro medio. Si estoy dentro del pblico objetivo, se supone que cualquier contenido publicado por un sitio es para m comprensible en el nivel pienso y entiendo. Pienso y entiendo es el mecanismo omnipotente de la interaccin, es quien puede resolver cualquier problema y transmitir cualquier contenido o concepto. Pero lo hace a un costo elevado para el visitante: requiere un gran esfuerzo. La prctica y los test muestran que este esfuerzo para aplicar razonamiento a la digestin de los contenidos que le presentamos es tan considerable que si el premio no es significativo, los visitantes se sentirn fuertemente defraudados. En general, ser muy pesimista en la previsin de cunto esfuerzo dedicarn los visitantes para comprender nuestro sitio es una buena forma de acercarse a la realidad, aunque la mayora de las veces es an peor.
Estructura y contenido
La Web tiene la particularidad de que los textos e imgenes que presenta son a la vez estructura y contenido. Esto no pasa en un libro: la estructura es el papel, la encuadernacin y la tinta, el contenido es el texto en s mismo. Se navega un libro cambiando las pginas, poniendo un marcador, revisando si la pgina que estoy leyendo esta cerca del principio o del final. En la Web, la estructura y por ende la navegacin est mezclada con el contenido: un ttulo es a la vez un link
y una opcin en la lista de resultados del buscador. Un botn es una etiqueta para una categora y un "hot spot" en el cual hacer clic. Para construir sitios fciles de usar y entender se debe tener en cuenta esta particularidad y aplicar de forma sistemtica los tres niveles de interaccin, siguiendo estas pautas:
Cuanto ms cerca de miro y entiendo, ms fcil de usar

El cerebro es una sofisticada herramienta de reconocimiento de patrones y por ello se desempea en esta tarea con destreza y eficiencia. Cuanto ms cerca de miro y entiendo y ms lejos de pienso y entiendo est un contenido ms fcil ser su comprensin. Hay que tener mucho cuidado con las falsas apariencias. La mayora de las veces un icono en un botn aparentemente pertenece al nivel de miro y entiendo, pero en realidad pertenece al ignoto nivel de pienso, pienso, pienso y sigo sin entender. Miro y entiendo es aplicable a los elementos ms bsicos de estructura visual, el agrupamiento, la jerarqua y el orden lgico. As como utilizarlo correctamente trae pinges beneficios, forzarlo ms all de sus posibilidades trae notorios inconvenientes.
La estructura y la navegacin no deben pasar de leo y entiendo

Los objetivos de los visitantes no incluyen en ningn caso conocer la estructura de un sitio o su jerarqua de categoras. Sus objetivos siempre estn anclados en el verdadero contenido del sitio, lo que habitualmente se llama el dominio de la tarea. Navegar en el sitio, comprender su estructura, su amplitud, su profundidad, son tareas ajenas al dominio de la tarea y por tanto deben requerir el mnimo de esfuerzo. Es por ello que no deberan alcanzar el nivel pienso y entiendo. Un ejemplo tpico de exceso en los requerimientos de comprensin es la utilizacin de cdigos de colores para indicar la pertenencia a secciones. Los test con usuarios muestran que ni siquiera usuarios habituales de un sitio son capaces de entender y utilizar estos cdigos, que son percibidos como mera decoracin. Los visitantes no se detienen a pensar el tiempo suficiente como para hacer un uso racional de los cdigos de colores, y su efecto es el contrario
al esperado, ya que producen links de todos colores o ttulos de psima legibilidad en amarillo sobre fondo blanco.
Manejar cuidadosamente la interaccin entre los niveles

El resultado ptimo se obtiene cuando los tres niveles interactan de forma adecuada. Ninguno de los tres por separado es suficiente para construir un sitio fcil de entender y usar. Cada uno de ellos tiene sus virtudes y sus dificultades, y la receta es el equilibrio.
Antes:
Despus:
Nuestros Productos
Nuestros Productos:
Impresoras Chorro de Tinta Matriz de Puntos Lser Cartuchos Cargas Lser Drivers Mantenimiento Repuestos Impresin Impresoras de chorro de tinta Impresoras de matriz de puntos Impresoras Lser
Suministros Cartuchos para chorro de tinta Cargas para impresora lser Drivers y actualizaciones de software
Servicio Tcnico Mantenimiento en nuestro taller y en el lugar Repuestos
Por ejemplo, cuando construimos una pgina con una lista de vnculos a seleccionar, como una lista de productos, el nivel miro y entiendo debe garantizar que la agrupacin, el orden, el tamao de la tipografa, las sangras permiten entender qu producto se emparenta con cul otro y qu es una categora, sin necesidad de leer el contenido. El nivel leo y entiendo debe garantizar que cada texto de la lista sea comprensible por s mismo, sin leer el resto de la lista, sin necesidad de recurrir a informacin adicional. El nivel
pienso y entiendo permite que una lista de productos hable de la empresa, de las tecnologas que soporta, de la variedad de su oferta, consigue transmitir ideas y conceptos ms all de lo que estrictamente se plasma en el papel. De ahora en adelante, cada vez que se enfrente a la tarea de crear contenido para una pgina, pregntese ante cada objeto creado a qu nivel corresponde. Si es necesario reescriba los contenidos de modo que la estructura y la interaccin no exijan llegar al nivel de pienso y entiendo, dejando este nivel para uso exclusivo de sus contenidos clave.
Mtodos de evaluacin de Usabilidad

Una de las principales actividades que se deben desarrollar es la evaluacin de los niveles de facilidad de uso de las interfaces. Hace 25 aos o ms los estudios de Usabilidad requeran costoso equipamiento y laboratorios especiales para llevar adelante el trabajo de campo, en la mayora de los casos con cientos de usuarios con el fin de obtener datos estadsticamente vlidos. El artculo "Usabilidad a un precio de descuento" de Jakob Nielsen presentado en setiembre de 1989 en la Tercera Conferencia Internacional de Interaccin Hombre Computadora signific un punto de inflexin en el desarrollo de metodologas para la evaluacin de Usabilidad. En primer lugar propona una metodologa completamente nueva, que denomin Anlisis Heurstico, para realizar un trabajo de revisin sistemtica de la interfaz de usuario a partir de las mejores prcticas de la industria. En segundo lugar, revolucion la realizacin de Test con Usuarios, argumentando que si se realizaban con una metodologa cualitativa en contraposicin a las metodologas cuantitativas que eran prctica habitual, era posible obtener resultados relevantes y valiosos con apenas 5 a 8 usuarios y en base a test realizados en un entorno mucho menos costoso que un laboratorio de Usabilidad. Veinte aos despus ambos mtodos son prctica comn y central en la evaluacin de la Usabilidad de sitios Web.
Anlisis Heurstico
El estudio de la interaccin entre el hombre y las computadoras (HCI - Human Computer Interaction) ha recorrido un largo camino que tiene su punto de partida en la dcada de los 70 del siglo pasado, o tal vez inclusive antes. En este perodo no solo ha investigado y producido mejores interfaces sino que ha acumulado un conjunto de experiencias y conocimiento que fueron sistematizados en reglas, guas y compendios de mejores prcticas, cuyo cumplimiento ayuda a conseguir interfaces ms fciles de usar. Estos conjuntos de reglas se conocen como Heursticas de Usabilidad. Las heursticas, reglas heursticas o el mtodo heurstico implican la solucin de problemas aportando soluciones suficientemente buenas a problemas complejos. Esta definicin tiene dos consecuencias relevantes:
La aplicacin sistemtica de Heursticas de Usabilidad aportar niveles de usabilidad suficientemente buenos sin necesidad de incurrir en metodologas o costos adicionales. Las Heursticas de Usabilidad son un principio: los niveles ptimos de usabilidad requieren la aplicacin de otras tcnicas y otros enfoques metodolgicos especficos, focalizados en la solucin de los problemas particulares a resolver.
Las 10 reglas heursticas

El abanico de compendios de Heursticas de Usabilidad es muy amplio y existen excelentes versiones con distintos atributos y foco en distintos temas. Tomaremos aqu como punto de partida una de las ms clsicas, la introducida por Jakob Nielsen y Rolf Molich en la conferencia "Evaluacin Heurstica de interfaces de usuario" en abril de 1990. Desde el '90 hasta la fecha han pasado casi 20 aos, en los que la Web ha impactado fuertemente en el diseo de las interfaces y las modalidades de interaccin, por lo que se impone una adaptacin al documento original que entendemos no alteran ni su esencia ni su espritu. Haberse mantenido vigentes durante casi 20 aos en un terreno donde se producen cambios continuamente y de un modo vertiginoso las hace enormemente valiosas.
1. Visibilidad del Contexto

El Sitio Web debe mostrar a los usuarios dnde se encuentran y de dnde vienen. Debe ser evidente si se mantienen dentro del sitio o si salieron de l.
Esta es una de las reglas claves para la navegacin en su relacin con la Arquitectura de la Informacin, como la herramienta que permite al usuario comprender la dimensin del universo de informacin disponible en el sitio, as como los caminos para recorrerlo. La interfaz del sitio debe ser capaz de construir para el usuario ese contexto e indicarle en todo momento qu relacin tiene la porcin de informacin que est visualizando con el resto de la informacin disponible en el sitio.
2. Coincidencia entre el sistema y el mundo real

El Sitio Web deber expresarse en el lenguaje del usuario, con palabras, frases y conceptos que le sean familiares, cuidndose de no hacerlo con trminos propios del sistema informtico. Seguir las convenciones del mundo real, desplegando la informacin en un orden natural y lgico.
Es muy difcil agregar conceptos tiles a una afirmacin tan concisa y llena de significado. Sin embargo la navegacin por la Web muestra que es una heurstica violada sistemticamente, elevando innecesariamente la dificultad de uso de un sitio al obligar al usuario a entender un lenguaje que les es totalmente ajeno.
3. Libertad y Control por parte del usuario

El Sitio debe imponer la menor cantidad posible de restricciones a los usuarios, permitindoles elegir los caminos y las formas de cumplir sus objetivos. Evitar desactivar los controles del navegador.
Es frecuente encontrar limitaciones en el uso de los sitios que tienen su origen en requerimientos tcnicos, decisiones organizacionales y otro abanico de fuentes que son invisibles al usuario. Si no hay una alternativa mejor, estas restricciones "suben" a la superficie, imponiendo una forma de interactuar distinta de la lgica y natural. Una prctica comn para imponer formas o caminos de interaccin es deshabilitar todo o parte de las funciones que proporciona el navegador que contiene el sitio Web (botones, barra de direcciones, achicar y agrandar la ventana, etc.). Esto genera mltiples problemas de Usabilidad, ya que desde el punto de vista del usuario la interaccin con un sitio particular siempre forma parte de un proceso ms amplio de navegacin constituido por una sucesin de pginas y sitios que se visualizan en forma secuencial o concurrente. Se estima que el navegador participa en el entorno del 35% en la navegacin en Internet, siendo la barra de scroll y el botn "atrs" los que llevan la mayor porcin de uso.
4. Consistencia y Estndares
Los usuarios no deben tener necesidad de discernir si palabras, situaciones o acciones distintas significan lo mismo. Seguir las convenciones de la Web.
Los estndares aportan grandes dosis de Usabilidad cuando se utilizan de forma consistente. Su efecto puede verse desde el punto de vista del micro y macro aprendizaje. Podemos hablar de microaprendizaje cuando un usuario es capaz de aplicar inmediatamente al resto del sitio lo que aprendi en su interaccin. Por ejemplo: si en una pgina del sitio las opciones del men despliegan ayuda al detener el puntero del ratn sobre ellas, el usuario utilizar este efecto en la pgina siguiente. Un sitio que se preocupa de que los visitantes puedan aplicar sus microaprendizajes a travs de un uso consistente de los elementos de la interfaz,
premiar a sus usuarios con una cantidad enorme de oportunidades para aplicar lo aprendido, devolviendo un enorme valor como pago por el esfuerzo que el usuario entreg al usar el sitio. El macroaprendizaje hace referencia a la aplicacin de estndares y convenciones que el usuario aprendi en otros sitios. Por ejemplo: el texto azul subrayado es sinnimo universal de vnculo y cualquier usuario lo reconocer en el nivel miro y entiendo, sin necesidad de razonamiento adicional. La aplicacin sistemtica de las convenciones y estndares de la Web, que el usuario trae como bagaje de conocimientos cuando llega al sitio, no solamente proporcionar una interfaz ms fcil de usar a los visitantes, sino que adems permitir aplicar los recursos del equipo de programacin y diseo a los elementos de la interfaz que son particulares del sitio.
5. Prevencin de Errores
Sensiblemente mejor que buenos mensajes de error es un diseo cuidadoso que anticipa y previene la ocurrencia de los problemas. O se eliminan las condiciones que conducen a error o se verifican y se advierte al usuario antes de que confirme la accin. Soportar deshacer y rehacer.
No todos los errores son evitables, pero gran parte de ellos pueden sencillamente eliminarse con un diseo cuidadoso de la interfaz. Por ejemplo, cuando el valor que puede ingresar un usuario en un campo est restringido a una pequea lista, un campo de texto abre la posibilidad a un sin nmero de errores, mientras un combo elimina totalmente la posibilidad de que ocurran. Reducir las posibilidades de error es siempre la mejor estrategia, ya que producen una navegacin fluida y dentro del modelo mental del usuario. Visto desde otro punto de vista, un error implica que la interfaz no fue lo suficientemente explcita para que el usuario comprenda qu opciones son vlidas y cules no lo son. Entonces prevenir los errores implica mejorar la comprensin que el usuario tendr de la interfaz y por tanto mejorar los resultados que obtendr al usarla.
6. Reconocer es mejor que recordar

Minimizar la carga en la memoria del usuario haciendo los objetos, acciones y opciones visibles. El usuario no debe tener necesidad de recordar informacin de una pgina a la siguiente. Utilizar la agrupacin visual, los tamaos y otras herramientas grficas para mostrar relaciones, dependencias y otras caractersticas sin necesidad de leer los textos.
Existen numerosas tcnicas para presentar informacin en la pantalla que ponen foco en la comprensin de la informacin que se despliega. Utilizar estas tcnicas reduce el tiempo que el usuario requiere para recepcionar el mensaje que el contenido intenta transmitir, valorar sus implicancias y sopesar las consecuencias de las decisiones que tiene que tomar al navegar. El camino opuesto es el de no desplegar informacin, recargando la memoria del usuario con datos innecesarios que podran estar en la pantalla. Permitir a los usuarios reconocer en la pantalla la informacin relevante es la herramienta fundamental para pasar del nivel pienso y entiendo a los niveles inferiores leo y entiendo, miro y entiendo.
7. Flexibilidad y eficiencia de uso

El Sitio Web debe estar optimizado para minimizar el esfuerzo que requiere al usuario alcanzar sus objetivos. No solicitar jams informacin innecesaria, acortar al mnimo los formularios y procesos. Los aceleradores (invisibles para el usuario novato) permiten que el sistema pueda satisfacer tanto a los usuarios inexpertos como a los expertos. Cuando el uso es reiterado, permitir a los usuarios personalizar las acciones frecuentes.
Cul es el alcance del sitio? La respuesta a esta pregunta est fuertemente vinculada a esta heurstica, porque la mayora de los casos en los que la interfaz se aparta de ella es precisamente porque el diseo transgredi las fronteras del alcance. Por ejemplo, en un formulario Web para poder realizar un trmite que antes era slo presencial se solicitan datos innecesarios para poblar la base de datos de usuarios o para cualquier otro fin. Es evidente que se est castigando al usuario a la vez que se est produciendo una desviacin del punto de partida original, ya que no tiene sentido hacer las cosas ms difciles para que sean ms fciles. El camino correcto es hacerlas lo ms fciles posible sin ms trmite.
8. Diseo minimalista y esttica

Las pginas no deben contener informacin que sea irrelevante o remotamente necesaria. Cada unidad extra de informacin compite con las unidades relevantes de informacin y reduce por tanto su visibilidad relativa.
La interfaz es una herramienta, un camino para que el usuario cumpla objetivos que en definitiva son ajenos a la interfaz. Si bien proporcionar una experiencia de interaccin agradable es un requisito de usabilidad, convertir la interfaz en la estrella es un error ya que desplaza a un segundo plano de relevancia los objetivos del usuario.
La aplicacin de una esttica equilibrada y acorde con el estilo de la organizacin duea del sitio es necesaria y bienvenida. No obstante, es necesario sopesar correctamente la necesidad de cada pxel que se incluye en la pantalla, cuidando de que su funcin ayude al usuario y no se transforme en el obstculo a sortear.
9. Escribir para la Web

Los textos y otros contenidos deben estar optimizados para la Web desde el punto de vista de los usuarios. Titular, usar vietas, listas y otras herramientas para maximizar la capacidad de buscar y ojear. Cuidar que la tipografa y el contraste de los textos no afecten la legibilidad.
Cada medio de comunicacin tiene sus particularidades y la Web no es una excepcin. Optimizar los contenidos para el medio es una tcnica que la humanidad domina hace siglos. El hecho de que la Web sea un medio muy nuevo en comparacin con los decanos, como la novela, el cuento o inclusive el cine, no nos exime de trabajar fuertemente para hacer que la relacin medio/mensaje sea equilibrada y permita a quienes reciben el mensaje a travs del medio obtener el mximo resultado con el menor esfuerzo.
10. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores

Los mensajes de error deben expresarse en lenguaje habitual (no cdigos o jerga), indicar con precisin el problema y sugerir constructivamente una solucin.
A pesar de todos los esfuerzos de programacin y diseo es inevitable que los usuarios arriben a situaciones inconsistentes, hecho que les es reportado a travs de los mensajes de error. El objetivo del mensaje debe, siempre que se posible, traspasar el objetivo puntual de comunicar la situacin de error, incluyendo una explicacin para que el usuario entienda por qu sucedi el error, qu consecuencias tiene y cules son los caminos para resolverlo. Si fuera el caso, el ptimo es que el mensaje de error incluya los vnculos o botones para que el usuario acceda directamente a los caminos de solucin sin ms trmite.
Analizando el sitio
El Anlisis Heurstico es una tcnica exhaustiva. Para llevarlo adelante es necesario recorrer en forma sistemtica cada una de las pginas del sitio, poniendo particular atencin en el contenido, las herramientas de navegacin, las agrupaciones lgicas de objetos, la redaccin y titulacin y los elementos
complementarios a stos que pudieran ser relevantes en cada caso, con nfasis en aquellos elementos o decisiones de diseo que se apartan de las Heursticas de Usabilidad o que se entiende que presentan dificultades para los usuarios.
Problemas Generales y Problemas Particulares

Dentro de los problemas que se detectan al realizar un Anlisis Heurstico a un sitio Web, algunos de ellos se repiten en una cantidad importante de pginas o en toda una rama de la navegacin. Llamaremos a estos problemas generales, en contraposicin a los problemas que suceden una o a lo sumo un puado de veces, a los que llamaremos problemas particulares. Los problemas generales a en la mayora de los casos tienen su causa en errores u omisiones en niveles ms profundos que el de la interfaz, como el Modelo de Interaccin o la Arquitectura de la Informacin. La deteccin de los problemas generales es ms relevante y ms til que la de problemas particulares porque su correccin mejora la usabilidad de porciones ms extensas de la interfaz. Es por ello que el Anlisis Heurstico debe privilegiar la deteccin de los primeros frente a los ltimos.
La severidad de los problemas

El Anlisis Heurstico debe producir un informe que detalla cada uno de los puntos en los que la interfaz se aparta de las mejores prcticas y la explicacin de porqu se aparta de ellas. En la mayora de los trabajos se incluye tambin una recomendacin de cmo superar el problema. Una prctica habitual es calificar cada problema detectado con un nivel de severidad, en base a una clasificacin similar a la siguiente: Severidad 1 - Problema grave de Usabilidad Es imperativa su solucin antes de liberar el sistema o de inmediato si el sistema est en produccin. Severidad 2 - Problema mayor de Usabilidad Es importante su solucin, y debera asignrsele alta prioridad. Severidad 3 - Problema medio de Usabilidad Solucionar el problema debera asignrsele baja prioridad. Severidad 4 - Problema menor de Usabilidad La solucin puede esperar al prximo proceso de rediseo de la interfaz.
El solo hecho de que un problema sea general hace que su severidad sea mayor, frente a la ocurrencia de un problema equivalente pero particular, es decir, restringido a una nica pgina. Al hablar de la severidad de los problemas e incluir expresiones como problema grave y solucin inmediata es importante reafirmar que a diferencia de otras reas tcnicas donde una falta grave, como por ejemplo una falla en la base de datos o un corte de energa, invalidan el uso del sistema completo, los problemas de Usabilidad, incluso los ms graves, no generan interrupciones generales y abruptas. Todas las interfaces se pueden usar: hasta la versin ms complicada construida por el cerebro ms retorcido puede ser utilizada. Cuando se indica que el problema de Usabilidad es grave y debe ser resuelto lo antes posible, se est asumiendo que quien administra el sitio tiene una preocupacin real por que sus visitantes encuentren contenidos valiosos y cumplan sus objetivos en el sitio de una forma rpida y satisfactoria. Es en a partir de este supuesto que alejarse de la facilidad de uso puede constituirse en un problema grave.
Ver los problemas uno a uno

Una caracterstica importante del Anlisis Heurstico es que cada problema detectado se analiza por separado, tanto para su determinacin como para proponer una solucin. Dicho de otra forma, se trabajan los problemas uno a uno, con el mayor nivel de granularidad posible, considerando al proponer la solucin que el resto del sitio quedar exactamente igual. Es por esta caracterstica que se dice que es una tcnica exhaustiva.
Cmo redactar los problemas y las recomendaciones

Para redactar los problemas y las recomendaciones el primer paso es capturar la pantalla donde ocurre el problema, sobre ella, con un editor de texto o de imgenes, marcar el lugar donde ocurre el problema y asignarle un nmero. En una captura de pantalla pueden incluirse ms de un problema. Es ms, habitualmente las capturas quedan colmadas de nmeros que indican problemas de Usabilidad.
En el texto indicar el nmero asignado como referencia, qu heurstica viola y cul es el grado de severidad. Por ejemplo: 3. Heurstica 6 - Reconocer es mejor que recordar. Severidad 1 Luego indicar: cul es el problema, cul es la causa del problema y cul o cules son las consecuencias para el usuario. Por ejemplo:
Problema: Los ttulos no se reconocen como tales porque el tipo de letra es muy pequeo y estn separados del texto, obligando a los usuarios a leer el cuerpo del contenido para determinar si la pgina ser til.
En este caso: Cul es el problema? los ttulos no se reconocen como tales Cul es la causa?: el tipo de letra es muy pequeo y estn separados del texto Cul es la consecuencia?: obliga a los usuarios a leer el cuerpo del contenido para determinar si la pgina ser til.
En mltiples ocasiones es evidente a partir del problema cul es su causa, cules son sus consecuencias o ambos. En este caso sencillamente se omiten, evitando los textos obvios o triviales del estilo "confunde al usuario" o "genera problemas de usabilidad".
Por ltimo incluir una recomendacin:

Recomendacin: Aumentar sensiblemente el tamao del tipo de letra y alinear los ttulos con el texto, de modo de que se reconozcan como ttulos sin ambigedades.
Una buena recomendacin tiene que decir qu hacer de la forma ms concreta y directa posible. Si el problema es "la paleta de colores es confusa" una recomendacin del estilo de "cambiar la paleta de colores para que sea menos confusa" no representa aporte alguno. En este caso la recomendacin debera decir cmo cambiarla, qu colores eliminar y cules agregar. Juntando todos los elementos, la redaccin quedara como sigue: 3. Heurstica 6 - Reconocer es mejor que recordar. Severidad 1 Problema: Los ttulos no se reconocen como tales porque el tipo de letra es muy pequeo y estn separados del texto, obligando a los usuarios a leer el cuerpo del contenido para determinar si la pgina ser til. Recomendacin: Aumentar sensiblemente el tamao del tipo de letra y alinear los ttulos con el texto, de modo de que se reconozcan como ttulos sin ambigedades.
Test con Usuarios

Los Test con Usuarios son hace ms de dos dcadas una prctica extendida en el proceso de concepcin y depuracin de interfaces de usuario para mejorar su facilidad de uso. Consisten en la observacin del comportamiento de individuos reales, los usuarios, enfrentados a tareas comunes, similares a las que se enfrentan en la vida real y que deben resolver utilizando el sitio Web. Se trata de una tcnica que permite detectar reas de conflicto, problemas de interpretacin y omisiones, de modo de poder perfeccionar el diseo de la interfaz. Los Test con Usuarios, tal como los describimos aqu, son una tcnica cualitativa. Es el equipo que planifica y realiza el test el que sacar las conclusiones y recomendaciones a partir de lo que suceda en el test, segn los objetivos planteados, su conocimiento de Usabilidad y la propia participacin de los usuarios. A diferencia de la esencia exhaustiva y abarcativa del Anlisis Heurstico, los test con usuarios son una tcnica focalizada, que permite el anlisis profundo de una cantidad reducida de problemas. Estas caractersticas los hacen complementarios, constituyendo una prctica habitual:
Realizar un Anlisis Heurstico como primer acercamiento al sitio. Esto permitir adems de tener un listado inicial de problemas y recomendaciones, un conocimiento profundo del sitio que se analiza, sobre todo si el equipo de trabajo en Usabilidad es ajeno al diseo y desarrollo del mismo. Determinar las reas de conflicto en base al heurstico y a partir de sus resultados. stas sern tomadas como base para la realizacin de los Test con Usuarios Testear con Usuarios para profundizar el descubrimiento de problemas en las reas de conflicto y a partir de ese conocimiento ms profundo poder proponer mejores soluciones.
Cuando se disea un test de usabilidad se debe evitar analizar problemas completamente conocidos ya que no produce resultados tiles y frustra enormemente a los usuarios que realizan el test, dado que solamente les pediremos tareas que la interfaz hace difciles de realizar. Los test deben estar orientados a descubrir problemas que no conocemos, a profundizar en la deteccin de fallas de Usabilidad. Lo que est mal hay que corregirlo sin ms trmite.
El desarrollo de los Test de Usabilidad

Para la realizacin de los Test de Usabilidad se utiliza la tcnica denominada "pensamiento manifiesto" (Think Aloud Protocol) en la que un moderador del test le propone a un usuario la realizacin de una serie de tareas en el sitio Web a analizar, solicitndole que relate en voz alta las acciones que lleva a cabo, las razones por las que las realiza, as como sus impresiones generales y particulares sobre el sistema. El orden esquemtico de las tareas que involucran un Test es el siguiente: 7. Se realiza la seleccin de usuarios en base a un perfil preestablecido. 8. La experiencia muestra ampliamente que 8 usuarios son suficientes para detectar los problemas. Inclusive en la mayora de los casos alcanza con apenas 5 usuarios. Y en el peor de los casos, un usuario es infinitamente mejor que ninguno. 9. En lo que respecta al perfil, este es muy relevante cuando el dominio de la tarea a testear tiene caractersticas particulares. En general es siempre vlido que los informticos de cualquier especie no deben ser usuarios en los test ya que tienen una visin completamente distinta de cmo
funcionan los sitios que los usuarios habituales. Tambin es recomendable excluir al equipo de desarrollo del sitio. 10. Se propone una lista de tareas adecuadas al perfil y focalizadas en el objetivo del estudio, plasmadas en un script. 11. Para que el test sea til, las tareas deben establecerse previamente y ello incluye como elemento fundamental redactar toda la informacin que se va a dar al usuario en cada una. Pensar cada palabra, definir si se utiliza o no un trmino que figura en la pantalla, entre otros, sern determinantes a la hora de contar con un test de calidad. 12. El moderador observa y escucha la evolucin del usuario. Lee una a una las tareas al usuario y mientras ste las desarrolla toma nota de los problemas y observaciones de inters para futuros anlisis. 13. Es importante recordarle al usuario que "piense en voz alta", pidindole que explique verbalmente qu est haciendo y por qu lo est haciendo. 14. Se filman y graban las sesiones, incluyendo las acciones, los comentarios y las expresiones de los usuarios, para su anlisis posterior. Hace unos aos filmar las sesiones requera de costoso equipamiento y era fuertemente intrusivo, ya que implicaba la presencia de trpodes y cmaras filmadoras en el lugar del test. Hoy en da existe software, como por ejemplo Camtasia Studio, que captura toda la actividad de la pantalla y filma al usuario con una cmara Web. Los Test con Usuarios se deben desarrollar en un ambiente controlado. El usuario es asistido por un moderador, que le explica las tareas pero que no interviene ni asiste la actividad del usuario con la computadora. A partir de la observacin directa en las sesiones y del anlisis de las grabaciones se determina la cantidad de tareas completadas satisfactoriamente y el conjunto de problemas a ser resueltos. Esto constituye un insumo fundamental para el trabajo de rediseo de la interfaz, de modo de reducir al mnimo posible las dificultades en el uso.
Redactar para la Web

Cada medio tiene su lenguaje
Ningn medio de comunicacin tiene una ley inflexible que determine cmo se generan contenidos de calidad. Es que la comunicacin no es una "ciencia dura" y por tanto no tiene ni teoremas, ni axiomas, ni estructuras formales estrictas que separen lo bueno de lo malo. Esto no inhibe a cada medio de comunicacin de tener sus reglas y pautas, los lineamientos que indican como generar contenidos de calidad. Luego cada autor utiliza estas pautas a su favor, segn su mejor saber y entender. En algunos casos, respetndolas a rajatabla. En otros, traspasando las fronteras de las recomendaciones a la bsqueda de efectos distintos, resultados innovadores. En la mayora de los casos, respetando algunos e ignorando otros. La Web no escapa a estos condicionamientos. La forma en que se utiliza, las caractersticas tcnicas del medio y el tipo de informacin que comunica determinan un formato de interaccin de los internautas con el medio que se transforma en patrones comunes de comportamiento. Dicho en otras palabras, existen comportamientos esperables, formas de actuar altamente probables en los visitantes. A pesar de lo joven de la Web en comparacin con otros medios, es posible determinar un cuerpo de lineamientos que permiten aprovechar estos comportamientos esperables de los futuros visitantes de nuestro sitio. Cada autor, har un uso consciente y creativo de estos lineamientos.
Cmo leen los internautas

En contra del sentido comn, las pruebas de campo reafirman una y otra vez que los internautas navegan por la Web de una forma muy poco sensata y racional. Prcticamente no leen, dejan casi todo por la mitad, no ven lo que est delante de sus narices y pierden muchsimo tiempo explorando opciones que no tienen nada que ver con lo que buscan, por la sencilla y nica razn de que no dedicaron 5 segundos ms a pensar si les convena o no hacer clic un link. Esta constatacin aparece de diversas formas en distintos estudios. Desde el punto de vista de Steve Krug7, los usuarios navegan a los tumbos, dndose golpes contra una y otra cosa hasta que encuentran lo que quieren. Segn J.
Steve Krug: Don't Make Me Think. New Riders, Indianpolis, USA, 2000
Morkes y J. Nielsen8, los usuarios no leen sino que ojean, escudrian (to scan), repasan las pginas con la mirada. Tal vez la investigacin ms interesante sea la aplicacin del conocimiento que se tiene de las actividades de caza de los grandes depredadores a la "caza de informacin" que los humanos realizamos frente a un flujo de informacin proveniente de un medio de comunicacin, realizada por Peter Pirolli y Stuart K. Card en 19939. Segn los autores, cada pieza de informacin podra asimilarse a una posible presa de caza, y el cazador pondr en la balanza el esfuerzo para cazarla, la probabilidad de fracasar, el beneficio esperado al obtenerla y el hambre acumulada, generando una compleja ecuacin que se ejecuta en instantes y de forma casi inconsciente para intentar determinar la mejor decisin a tomar. No se trata de una estrategia de mediano o largo plazo implementada con pequeas acciones alineadas con el objetivo, sino de una serie de micro-decisiones desconectadas movidas por un incentivo poderoso: el hambre. As como una leona decide en fracciones de segundo si es mejor atacar a una cebra vieja y de carne dura pero presa fcil que a un macho joven, de carnes ms tentadoras pero presa ms difcil, los humanos decidimos los distintos caminos de bsqueda, recuperacin y consumo de la informacin entre las diversas opciones y posibilidades que se nos ofrecen. Los visitantes de nuestros sitios los recorren como si estuvieran en uno de esos videojuegos de carreras de autos, donde quedan unos segundos para llegar a una meta que nos dar 10 o 15 segundos ms de vida para llegar a la prxima meta. La consecuencia es que el primer link que encuentran, del que perciben que tendr alguna remota probabilidad de tener algn contenido cercano a lo que estn buscando, ser seleccionado sin ms anlisis. No es sensato, no tiene sentido, parece increble, pero la experiencia prctica y la investigacin sistemtica refuerzan este hallazgo una y otra vez. El arte de escribir para la Web no es el arte de crear contenidos para nuestros lectores, sino todo lo contrario, el arte de escribir para alguien deseoso de no-leer.
Algunas consecuencias de la forma de lectura en la Web

A continuacin se describen algunas conclusiones que se extraen a partir de los trabajos antes mencionados:
John Morkes and Jakob Nielsen: Concise, SCANNABLE, and Objective: How to Write for the Web http://www.useit.com/papers/webwriting/writing.html - 1997 9 Peter Pirolli and Stuart K. Card - Informatio Foraging http://www2.parc.com/istl/projects/uir/pubs/items/UIR-1999-05-Pirolli-Report-InfoForaging.pdf - 1993
Los usuarios quieren buscar - buscar es una forma rpida de recorrer el contenido sin mirarlo. Ya sea utilizando buscadores externos, el buscador del propio sitio o la bsqueda del navegador, buscar es siempre una estrategia vlida para no leer. Esperar es desagradable - Nada que haga esperar a un usuario ser bienvenido. Prcticamente no hay recompensa que haga vlida una espera. La ms tentadora promesa ser desechada sin piedad si implica una espera, aunque sta sea aparentemente pequea y justificable. Las guas convencionales de buena redaccin son buenas Organizar cuidadosamente la informacin, utilizar un vocabulario adecuado a la audiencia esperada, titular correctamente, limitar cada prrafo a una idea, proveer una cantidad adecuada de informacin, son todas normas tradicionales que garantizan una calidad aceptable para los contenidos de las pginas Web Escribir de forma simple, directa y con un toque de informalidad Los visitantes esperan encontrar la informacin que buscan sin recovecos ni filigranas. La forma simple y directa es la preferida, y dentro de los tonos, un toque de informalidad es bienvenido. La credibilidad es vital - los visitantes evalan permanentemente la credibilidad de los contenidos que leen en la Web. La fuente, el autor, el sitio en el que estn publicados, los links a otros sitios, el formato, son todos elementos que aportan a la hora de definir si el contenido es creble y veraz. Ante un sitio desconocido o un autor desconocido, el punto de partida est ms cercano a la desconfianza que a la conviccin de veracidad. El humor debe ser utilizado con cuidado - Si bien un toque de informalidad puede ser un aporte, el humor es un arma de doble filo. La permanencia de los contenidos en el tiempo, que los hace salir del contexto en el que fueron escritos, el carcter planetario de la Web y la diversidad cultural de los pblicos que acceden, hace que las referencias ambiguas, las sustituciones y los juegos de palabras que aportan humor hagan parecer a los sitios en muchos casos como tontos o presumidos. El hipertexto es bienvenido - La Web es eso: un gran espacio hipertextual. El hipertexto permite administrar la cantidad, calidad y complejidad de los contenidos a los que se accede, dejando en el visitante la decisin de profundizar o continuar, algo que funciona muy bien.
Estilos de escritura
Cuando un autor se enfrenta a la tarea de crear un texto, tiene delante de l un abanico infinito de opciones de estilo. Este es uno de los temas ms escurridizos a la hora de generar clasificaciones y donde la destreza del autor hace ms diferencia. De todos modos, hay algunas recomendaciones posibles a la hora de escribir para la Web. Escritura Objetiva: En contraposicin con la escritura promocional, rica en adjetivos, metforas y autoalabanzas, en la Web funciona mejor el estilo objetivo, parco en adjetivos, frases irrelevantes y muy, pero muy mesurado a la hora de elogiarse a s mismo. Escritura Concisa: La comprensin y recordacin de textos en la Web se ve incrementada cuando los textos estn escritos con un estilo conciso, compacto. Esto tiene sentido si se parte de la base de que los visitantes leen poco. En general, si el punto de partida es un folleto promocional, un texto conciso escrito para la Web contendr solamente entre un 30 y un 50 por ciento del texto original. Escritura ojeable (scannable): La utilizacin de ttulos, subttulos, resmenes, copetes, colgados, distintos tamaos de letra, resaltados en negrita, etc. permite ojear el contenido del documento sin obligar a una lectura secuencial. Prrafos cortos (entre tres y seis renglones) funcionan muy bien, cada uno conteniendo una nica idea.
Estos tres estilos pueden ser combinados, obteniendo as resultados ptimos.
Tcnicas de escritura para la Web

Escritura tipo Pirmide invertida
Es de estilo en muchos medios escritos el desarrollo lgico y secuencial de los razonamientos, motivos y fundamentaciones para arribar paso a paso a las conclusiones que se expondrn al final. El modelo cannico de este estilo est dado como por ejemplo la estructural de una tesis: exposicin del problema a tratar, seguido por las hiptesis del trabajo, una resea exhaustiva del material existente al respecto, luego una descripcin detallada de la metodologa de investigacin,
la resea completa del trabajo de campo, una seccin de resultados con todas las tablas de datos obtenidos para arribar al final a una seccin de conclusiones, que a partir de todo lo expuesto analiza la validez de las hiptesis previstas originalmente, a lo que se suman otros hallazgos no considerados en las hiptesis.
Esto es lo que se llama escritura en Pirmide, donde a partir de la exposicin de distintas capas de contenido se construye un cimiento slido del cual se derivan las concusiones. La prensa hizo suyo el estilo opuesto, la pirmide invertida: primero las conclusiones, luego las explicaciones y al final los detalles. Este estilo se adecua muy bien a la Web. A diferencia de la escritura piramidal tradicional, este estilo permite que quien lee interrumpa la lectura en cualquier momento y que el contenido que ley tenga sentido completo, variando el nivel de detalle de la informacin segn el momento en el que dej de leer.
"Decir, Decir y Decir"

Una tcnica de escritura muy til a la hora de crear contenidos Web es la tcnica de "Decir, Decir y Decir". Segn esta tcnica, cada documento debe estructurarse con un resumen de su contenido, seguido de la ampliacin del contenido y por ltimo un resumen de cierre. De esta forma, la misma idea se expresa tres veces de tres formas distintas, con tres niveles de detalle distintos, de ah el nombre de Decir, Decir y Decir. La utilizacin de esta tcnica ayuda la lectura no secuencial tpica de los visitantes de un sitio Web, ya que la lectura parcial da de por s una idea razonablemente completa del conjunto del contenido del texto.
Escritura auto-similar
10
Si partimos de un martillazo el televisor, obtendremos una coleccin de pedazos que nada tienen que ver con el televisor que les dio origen. Por el contrario, si partimos de un martillazo una piedra, obtendremos una coleccin de piedras ms pequeas, que a su vez pueden ser divididas en otras piedras y as sucesivamente. A esto se le llama estructura auto-similar. Existen en la
10
El concepto de Auto-similitud aparece con mucha fuerza en la teora Fractal, desarrollada por el matemtico polaco Benoit Mandelbrot, quien llam a esta propiedad "Sibilsimilitud", palabra que no figura en el diccionario de la Real Academia Espaola.
naturaleza y en la ciencia numerosas estructuras auto-similares. Por ejemplo: las nervaduras de una hoja tienen una estructura auto-similar, un segmento de recta es una forma auto-similar. Un texto auto-similar es un texto que al ser dividido en textos ms pequeos, cada uno de ellos sigue manteniendo sentido. La idea de auto-similitud le aporta al texto la capacidad de que el internauta elija qu partes del documento leer y en qu secuencia hacerlo, manteniendo la capacidad de transmitir el conjunto de ideas que el autor se propuso transmitir cuando lo escribi. Si partimos una novela en tres partes, inclusive aplicando un buen criterio y la mejor buena voluntad, no obtendremos tres novelas ms cortas. Sera deseable que si partimos en tres un contenido Web, obtengamos tres contenidos ms cortos, con menos detalle, pero que siguen teniendo sentido como contenidos Web.
Escritura en capas transparentes

Otra tcnica muy til es concebir el documento que se est escribiendo para la Web como la superposicin de varias capas transparentes, cada una de las cuales contiene todos los textos que pertenecen a un mismo nivel jerrquico. La capa de mayor jerarqua contendr probablemente el ttulo, que debe tener sentido en s mismo. La capa de jerarqua 2 contendr los subttulos. Al superponerla con la 1 obtendremos un documento que tiene el ttulo y los subttulos, asimilable a una tabla de contenidos del documento. Si la capa 3 contiene el resumen que sigue al ttulo y los destacados de cada prrafo, al agregarlo a las capas 1 y 2 obtendremos un documento similar al que tenamos, pero que ahora agrega un nivel ms de profundidad al contenido. Y as sucesivamente. La escritura en capas transparentes es sumamente efectiva a la hora de permitir hojear documentos, ya que es probable (y recomendable) que los contenidos usen tipografa ms grande cuanto mayor jerarqua tiene la capa a la que pertenecen. As el ojo del visitante podr recorrer la pgina Web seleccionando los tipos de letra mayores o iguales a un tamao dado (algo que los humanos hacemos inconscientemente, sin necesidad de ningn esfuerzo) y obtendr un contenido completo, razonable y con un nivel de detalle acorde al tamao seleccionado. Otra forma de ver la utilidad de la escritura en capas transparentes es que si el usuario lee solamente 25 palabras, hay gran probabilidad de que sean las que nosotros elegimos para la capa 1 o 2, con la preocupacin de que tengan sentido y entreguen un contenido til.
Organizando el contenido
Existen numerosas herramientas que permiten organizar, clasificar y jerarquizar el contenido, aportando legibilidad, comprensin y recordacin a las ideas que queremos transmitir. Forma y contenido interactan para mejorar o empeorar la calidad de la pgina Web, haciendo que en algunos casos un error en la eleccin del tamao del tipo de letra haga completamente ilegible un gran texto. Listaremos a continuacin algunos de los elementos a utilizar, los ms bsicos a utilizar.
El ttulo de la pgina
A pesar de la actitud de no-lectura que reina en la Web, se puede estar tranquilo que cualquier visitante que entre a una de las pginas Web leer como mnimo el ttulo. Esto realza su valor y aumenta el nivel de exigencia en su creacin. Un buen ttulo debe cumplir con dos requisitos bsicos: Debe ser el texto ms prominente de la pgina, colocado en un lugar absolutamente central y destacado (debajo del cabezal, arriba de todo otro contenido y alineado a la izquierda es el ideal). Es muy frecuente que aparezcan otros textos con igual o mayor destaque que el ttulo, lo que hace que el visitante deba pensar acerca de cul de ellos es el ttulo y por qu no parece el ttulo si realmente lo es. La prueba mxima de tamao y ubicacin del ttulo de la pgina es cambiar los caracteres a griego y preguntarle a alguien si puede sealar con su dedo el ttulo en la pantalla. Si lo hace sin errores, el ttulo est correctamente ubicado y tiene el tamao adecuado. El ttulo debe estar redactado de la forma ms directa posible, tratando de generar una expectativa exacta acerca del resto del contenido de la pgina. Despus de hacer clic en un link aparece una pgina. El visitante va a leer lo primero que encuentre (si el ttulo est bien ubicado y tiene un tamao preponderante ser probablemente el elegido) con el fin de decidir si lleg a un contenido til o debe seguir navegando/buscando. El ttulo tiene que estar redactado de forma de contestar a la mayor cantidad de visitantes esta disyuntiva sin ambigedades.
Los otros ttulos de la pgina

El resto de los ttulos, habitualmente llamados subttulos, cumplen con respecto al texto que encabezan el mismo rol que el ttulo cumple con el documento. Al igual que el ttulo de la pgina, su ubicacin y el tipo de letra deben indicar sin
ambigedades su condicin, lo que se puede traducir en una colocacin que marque cul es el texto que est encabezando y un tamao de letra que lo resalte como ttulo sin dejar dudas que no se trata del ttulo de la pgina sino de un ttulo secundario. En una ojeada a la pgina, un paquete de subttulos bien redactados y colocados (ms cerca del prrafo que titula que del anterior), dan un pantallazo rpido, completo y con poco esfuerzo de qu es lo que vamos a obtener si leemos la letra chica de la pgina que estamos mirando.
Las listas
En la Web funcionan muy bien en la mayora de los casos las listas con vietas (bullets) y las listas numeradas. En general, siempre que hay que enumerar cosas o conceptos, las listas con vietas son una herramienta que mejorar nuestra pgina. Las listas permiten adems agregar contenido sin empastar el total, al permitir destacar a modo de ttulo las tres o cuatro primeras palabras del prrafo de cada vieta.
Los prrafos
Tal vez los prrafos sean los elementos ms discutibles. Sin embargo las pruebas de usabilidad muestran con claridad que hay muy baja probabilidad de que un internauta lea completo y de una vez un prrafo largo (ms de 8 renglones) y esta probabilidad baja si la letra es pequea. Hay alta probabilidad de que los visitantes lean solamente la primera lnea del prrafo o las dos primeras. En resumen: funcionan bien los prrafos cortos (entre 3 y 6 renglones) donde en la primera lnea se expresa una idea completa.
Los resmenes
No solamente el tradicional Abstract, Colgado, Bajada o Acpite que aparece en el encabezado de cualquier artculo puede ser utilizado como resumen. En la Web es extremadamente til agregar otros resmenes, ya sea en recuadros aparte o directamente en el texto, por ejemplo debajo de cada subttulo.
Ni magia ni dogmas
La comunicacin humana es un fenmeno altamente complejo, del que sabemos mucho e ignoramos muchsimo ms. En este marco no es sensato pensar que
con una lista de recomendaciones, sean cuales sean estas recomendaciones, vamos a garantizar mgicamente la creacin de contenidos de calidad. Por otra parte, alcanza con navegar por algunos sitios Web para darse cuenta que aplicando apenas algunas de las recomendaciones y un poco de sentido comn, su capacidad de comunicar aumentara enormemente. Ese solo hecho hace que el esfuerzo por sistematizar el conocimiento sobre cmo escribir para la Web sea vlido.
Formularios: la Web interactiva

Una forma til de dividir un sitio Web es entre las pginas para leer y las pginas para interactuar. La diferencia ms importante entre unas y otras es que las primeras son unidireccionales ya que la informacin fluye solamente del sitio Web al usuario. Las segundas son bidireccionales: el sitio emite un paquete de informacin y recibe la informacin del usuario como respuesta. La herramienta que brinda la Web para esta funcin es el formulario. La Usabilidad de las pginas que contienen formularios es notoriamente ms compleja que la de aquellas que slo publican informacin. No solamente el manejo del formulario requiere un uso ms intenso de la pgina sino que completar los campos correctamente tiene como requisito previo una comprensin acabada de la informacin presentada. Mientras que en una pgina informativa el primer clic probablemente implique el fin de la interaccin y la carga de una nueva pgina, a lo que se suma que la probabilidad de utilizar el teclado es muy baja, una pgina que contiene un formulario requerir varios clic y la digitacin de varios campos para cumplir con su finalidad.
Usabilidad de los formularios

A diferencia de las reglas heursticas, que tienen un carcter ms amplio y conceptual, la interaccin con los formularios requiere de pautas ms estrictas para garantizar niveles aceptables de Usabilidad. Al igual que con las reglas heursticas, alcanzar niveles ptimos de usabilidad implica complementar la aplicacin de las recomendaciones con el anlisis especfico de cada caso particular. Las recomendaciones que siguen tienen como base el trabajo de la profesional en Usabilidad espaola Olga Carreras, recogido en el artculo "Formularios Usables: 60 directrices de Usabilidad"11, que contiene adems una excelente resea bibliogrfica al respecto.
11
Formularios usables: 60 directrices de Usabilidad Olga Carreras
http://olgacarreras.blogspot.com/2007/02/formularios-usables-60-directrices-de.html
Estructura de un formulario
Un formulario se divide en los siguientes elementos (ver figura): 15. Ttulo del Formulario: describe todo el proceso, desde el primer paso hasta el ltimo. Se mantiene visible durante todo el proceso. 16. Pasos del proceso: es una secuencia que indica la cantidad total de pasos y una pequea descripcin de cada uno de los pasos a dar, donde el paso actual se encuentra resaltado. De los pasos ya cumplidos la descripcin incluye algn dato relevante de los ingresados por el usuario.
Esquema de un formulario usable
Ttulo del paso: describe el paso actual dentro de todo el proceso. Es distinto del ttulo del formulario y distinto para cada paso. Es muy bueno que incluya el nmero de paso en un texto del tipo "Paso X de Y". Grupo de campos: representan una agrupacin lgica de campos dentro de un paso. Estn enmarcados con un recuadro y llevan un ttulo de grupo alineado como en la imagen:
No hay un nmero mximo de campos para incluir en un grupo, pero es muy importante cuidar que cada uno de los pasos se mantenga en todo momento equilibrado. Acciones: todas las posibles acciones del formulario se encuentran al pie. Deben incluir siempre flechas que indiquen el sentido en que avanzan. Siempre debe haber una (y slo una) resaltada con el formato de botn que indique la accin a ejecutar por defecto. Las dems acciones se muestran como vnculos.
La tecla Intro tiene que funcionar en todos los casos de forma equivalente a realizar clic en el botn de la accin por defecto del formulario.
Los campos y sus etiquetas

El criterio de Usabilidad ms importante respecto de un formulario es que su complejidad crece exponencialmente con el aumento del nmero de campos que contiene, por lo que es absolutamente recomendable reducir la cantidad de campos al mnimo imprescindible. La situacin ideal es aquella en que se solicitan al usuario solamente datos obligatorios. Las etiquetas deben describir el contenido en los trminos del usuario, inclusive si esto implica una supuesta imprecisin desde el punto de vista de la nomenclatura interna de la organizacin.
Agrupacin y formato
Dentro de cada grupo se incluye un nmero razonablemente pequeo de campos relacionados por su naturaleza y contenido. Es deseable que los campos tengan, dentro de cada grupo, tamaos similares sin que esto implique que la cantidad de datos a introducir sea la misma. Esta definicin resiente la asociacin visual entre el tamao del campo y el largo de los datos que admite, pero el criterio adoptado es que el equilibrio visual genera una percepcin de facilidad de uso que compensa la prdida. Todos los campos se alinean a la izquierda, y sus etiquetas a la derecha. Esta alineacin privilegia la identificacin visual de la relacin etiqueta-campo.
Se recomienda especialmente incluir un nico campo y su correspondiente etiqueta por lnea. En particular, se recomienda prescindir de formularios con ms de una columna. En campos de una lnea, la etiqueta debe ir centrada verticalmente con el campo. En campos de ms lneas independientes (check boxes, radio buttons) la etiqueta va centrada verticalmente con el primer elemento. En campos multilneas la etiqueta va a una distancia vertical del borde superior equivalente a la que tiene en un campo de una sola lnea. Los campos de elementos independientes (check boxes y radio buttons) agrupan sus opciones verticalmente. Para listas de hasta 5 elementos, siempre es preferible esta opcin a los combo boxes y listas descolgables, ya que permiten la visualizacin simultnea de todas las opciones sin necesidad de realizar ninguna accin. Los campos obligatorios llevan la marca (*) al final de la etiqueta, nunca al lado del propio campo. Se debe aclarar en el formulario que sta es la marca de obligatoriedad, pero no es imprescindible hacerlo en un lugar de destaque, ya que es un estndar de amplia difusin en la Web.
Ayuda
Con respecto a la ayuda, la situacin ideal es aquella en la que todo lo necesario para completar el formulario est en la pantalla (aunque si es preciso est permitido generar documentos complementarios de ayuda), en base a las siguientes herramientas:
Ttulos y etiquetado: se deben pensar y testear las etiquetas, para evitar problemas de interpretacin o ambigedades. Las etiquetas incorrectas generan errores sistemticos de los usuarios, con el consiguiente aumento en el ndice de abandono. Ayuda en el campo: se puede incluir hasta 2 renglones de ayuda debajo del campo, con una fuente relativamente pequea. El texto debe ser breve y directo y en lo posible incluir ejemplos. Ayuda en el grupo: cuando sea imprescindible, se puede agregar hasta 3 lneas de texto arriba o debajo de los campos de un grupo (no en el medio) que describan con precisin el sentido o la utilidad del grupo de campos. Imgenes: en muchos casos, como por ejemplo cuando hay referencias a elementos fsicos, agregar una imagen implica un nivel de ayuda significativo, que justifica el desajuste que se genera en la apariencia y equilibrio del formulario.
Los datos del usuario

Mostrar los datos ya ingresados es una prctica recomendada y muy til, que ayuda al usuario a ubicarse a la vez que le genera tranquilidad: En los pasos del proceso hay espacio para algunos datos ingresados. Esto ayuda a la recordacin del paso, ya que es ms fcil para el usuario reconocer sus propios datos que el texto que el formulario tenga predefinido. Todas las confirmaciones deben proporcionar todos o al menos una cantidad razonable de los datos ingresados por el usuario. No se deben utilizar las confirmaciones del tipo "Est usted seguro?" sin informacin adicional.
El formulario debe hacer todos los esfuerzos necesarios por conservar los datos del usuario, inclusive si ste no hace nada para guardarlos. Cuando esto sea posible, se debe incluir una opcin especfica para vaciar los datos y volver a comenzar. En este caso la opcin debe ser pequea, nunca debe ser la accin por defecto y debe tener una pantalla de confirmacin que indique que la misma es irreversible.
Confirmacin
Todos los procesos deben terminar en una pantalla de confirmacin, que deje absolutamente claro y sin ambigedades: El resultado de la operacin: xito, fracaso u otro. Si la finalizacin de la operacin es el ltimo paso del proceso, o si es requerido seguir adelante Cules son las acciones y posibilidades que tiene el usuario a partir de ahora.
En algunos casos es razonable que esta confirmacin est incluida en una pantalla que tiene adems otras informaciones y contenidos, pero es en general una buena prctica dedicar una pantalla exclusivamente a este fin.
Manejo de errores y mensajes

En general podemos afirmar que siempre es preferible prevenir los errores, impidiendo que el usuario caiga en ellos, antes que corregirlos. Algunos ejemplos: siempre es preferible una lista a un campo de texto pleno, si el conjunto de valores aceptables es reducido. siempre es recomendable que al seleccionar una opcin se deshabiliten las otras opciones mutuamente excluyentes con la misma. aceptar cualquier formato es siempre preferible a exigir al usuario que utilice un formato dado, como por ejemplo en el caso de la cdula de identidad.
En el caso de que se produzcan errores, los criterios para su manejo son los siguientes: Es importante mostrar los errores cuando se detectan. El ptimo es al validar la pantalla que los contiene. En ningn caso se debe dejar avanzar a un usuario con errores pendientes de corregir. Esto excluye dejar avanzar en el formulario con campos en blanco, algo que en muchos formularios no solo es razonable, sino recomendable. Algunos errores deben ser validados en el momento de completar el campo. En algunos casos, el ptimo es validar el campo en el momento
en que se completa. Esto es vlido cuando la probabilidad de error es muy alta, como por ejemplo para determinar si un nuevo nombre de usuario ya est en la base de datos. Es malo mostrar errores uno por uno. Interrumpir permanentemente con mensajes de error es molesto y corta el flujo del formulario. La mayora de los errores debe chequearse al validar la pantalla y slo los de muy alta probabilidad deben chequearse en el momento en que se completa el campo. Los errores deben mostrarse junto al campo donde ocurrieron. Cuanto ms cerca est el mensaje de error del campo donde ocurri, mejor. Es necesario tomar en cuenta al implementar esta recomendacin que al mostrar un mensaje de error ste debe ubicarse siempre en la parte visible de la pantalla, sin necesidad de que el usuario realice ninguna accin adicional para verlo (por ejemplo, que tenga que recurrir al scroll del navegador). Cuando se muestra ms de un mensaje de error, es necesario incluir en el tope del formulario -debajo del ttulo del paso y antes del primer grupo- un cuadro de resumen que contenga todos los errores. Si este es el caso, aqu debe estar el foco, por lo que este mensaje debe quedar visible sin que el usuario realice ninguna accin. El rojo indica error. Los mensajes de error se escriben en rojo y este color no debe ser utilizado para ninguna otra funcin dentro de los formularios. Los campos con error deben indicarse visualmente de forma contundente. Los bordes rojos, fondos de tonalidades del rojo e conos rojos son una ayuda de mucho valor en esta tarea. No es recomendable utilizar Pop Ups para comunicar errores, ya que no es posible establecer un vnculo visual entre el campo de error, el mensaje de error y las recomendaciones.
Mensajes al usuario
En muchos casos es necesario comunicar al usuario informacin, por ejemplo la confirmacin del resultado de una accin o decisin tomada. Los criterios para estos mensajes son exactamente los mismos que para los mensajes de error, con la nica diferencia que utilizan la gama cromtica definida para los formularios segn el sitio y jams estn en rojo.
Recomendaciones particulares para elaborar buenos formularios

Se incluye una recopilacin de mejores prcticas en la creacin de formularios
Genricos
Pida slo la informacin absolutamente necesaria. Siempre que sea posible, infiera informacin a partir de otra disponible. Por ejemplo, del Cdigo postal se puede inferir la ciudad y el departamento. Reutilice los campos cuando sea posible. Jams pida la informacin dos veces. Por ejemplo, si el usuario ha rellenado la direccin de facturacin, no le obligue a volver a rellenar la direccin de envo si no es necesario, puede llenar el campo con el valor default y permitir que lo modifique si es distinto, o agregar un botn "Igual que en facturacin" para suprimir con un clic la necesidad de ingresar todos los datos dos veces. Nunca pida al usuario que decida entre opciones que no comprende. Por ejemplo, incluir un combo para decidir que versin de protocolo utilizar en las comunicaciones, cuando los usuarios no son tcnicos. O elije uno y elimina la opcin, o redisea el formulario incluyendo las consecuencias de la eleccin (este es ms seguro, este otro es ms rpido, el tercero produce menos errores, etc.)
Textos
Proporcione un ttulo al formulario que exprese claramente su funcin. Si necesita instrucciones, que sean breves y comprensibles. Utilice una nomenclatura clara y familiar, sin tecnicismos ni extranjerismos. Sea consistente en el uso de los trminos. Es decir, use siempre las mismas palabras para los mismos conceptos.
No utilice preguntas complejas ni haga pensar al usuario. Redacte siempre las opciones de forma afirmativa. Por ejemplo, junto a un checkbox escriba Deseo recibir el boletn" en vez de "No deseo recibir el boletn". Redacte las opciones de modo consistente. Por ejemplo, en todas las opciones 1 es mejor y 10 es peor, nunca mezclado.
Organizacin
Organice los campos en una sola columna de datos. Como siempre, hay muchos contextos de uso y excepciones justificables, como los formularios que se rellenan de forma repetitiva y constante, pero la excepcin nunca puede convertirse en norma. Organice los campos en grupos lgicos, utilizando para ello la mnima cantidad de elementos visuales (evitando as ruido visual). Agrupe, si es posible, los campos obligatorios al comienzo del formulario. Evite fragmentar la peticin de informacin. Por ejemplo, no pida por separado la calle, el nmero, el apartamento, etc. si no es estrictamente necesario. Proporcione un diseo ordenado, alineando verticalmente todas las etiquetas y todos los campos entre si. Site las respuestas de los campos radio buttons y check boxes despus de los mismos. De esta manera se favorece la alineacin vertical de todos los controles. Utilice etiquetas estndar para agrupar campos y hacer ms manejable la informacin (OPTGROUP, FIELDSET). Si se utilizan radio buttons o check boxes agrupe visualmente de forma clara y unvoca los distintos grupos de opciones.
Distinga visualmente los campos deshabilitados siguiendo las normas de facto (ponindolos en gris claro).
Tipos de campos
Evite los campos de texto ms angostos que el largo mximo permitido Homogenece los anchos de los campos de texto cuando estos sean similares (evitando as ruido visual). Dote a los campos de texto de flexibilidad para que admitan los datos en cualquier formato. Por ejemplo, un campo para introducir el nmero telfono debera admitir parntesis, guiones, espacios; un campo para introducir importes debera admitir decimales con punto o con coma, etc. Evite el uso de combos. Evite que los combos recarguen la pgina para rellenar otros campos, pero cuando as sea, asegrese de que el formulario conserva el mismo estado que tena antes de recargar la pgina: con los mismos campos visibles o activos, y con todos los campos rellenos con los mismos datos que antes de la recarga. Si se utilizan combos o radio buttons seleccione siempre una opcin por defecto, asegurndose de que sea la ms probable, como por ejemplo Uruguay en el caso del pas. Evale siempre en estos casos si es necesario incluya una opcin "Otro" o "Ninguna". Evite incluir opciones sin sentido, como las largas listas de idiomas o pases tomadas de otro sitio sin ms anlisis. En caso de que haya una lista larga de opciones vlidas, pero de muy baja probabilidad, seprelas de las pocas opciones altamente probables. Si se utiliza un checkbox para presentar una nica opcin que no es obligatoria (recibir publicidad, aceptar unas clusulas) no la marque por defecto. Si se utilizan radio buttons asegrese de que todas las opciones son mutuamente excluyentes Siempre es preferible utilizar radio buttons en vez de combos.
Si un radio button tiene ms de dos respuestas, colquelas en vertical, unas debajo de otras alineadas a la izquierda.
Funcionamiento
Valore la posibilidad de evitar, mediante JavaScript, que en determinados campos se pueda introducir determinados caracteres. Por ejemplo, que en el campo Documento de Identidad slo se puedan introducir nmeros, guiones y puntos, haciendo que el resto de caracteres no se puedan teclear en el campo. No implemente saltos automticos del foco del formulario. Deje que sea el usuario quien indica que complet un campo al pasar al siguiente con el tabulador o con el puntero del Mouse. Asegrese de que la tecla "Intro" realiza la accin principal. Evite, mediante JavaScript u otra tcnica, que el usuario pueda impacientarse y enviar dos veces el formulario por error. Al implementar la validacin de los formularios (o al limitar el tamao de los campos) piense si su formulario puede ser utilizado por usuarios de otros pases. Por ejemplo, el Documento de Identidad o el telfono no tienen la misma longitud en unos pases que en otros.
Ayudas
Identifique claramente los campos obligatorios y los opcionales. Incluya ayudas breves o ejemplos junto a los campos, pero slo cuando sea realmente necesario para saber cmo ingresar un dato.
Botones
Siempre es mejor que haya una nica accin primaria. No incluya jams un botn "Reset" (es decir, de Limpiar o Borrar el formulario). Distinga entre la accin primaria y las secundarias (volver, imprimir etc.) de su formulario.
Evite las secundarias, pero si ha de incluirlas distngalas visualmente de forma inequvoca, destacando visualmente la primaria. Por ejemplo, poniendo la accin primaria como botones y las secundarias como enlaces. Coloque los botones o enlaces que realizan las acciones primarias (por ejemplo el botn "Enviar") lo ms cerca posible del ltimo campo del formulario. Utilice un nombre adecuado para los botones del formulario, relacionado con su accin y no de carcter general. Por ejemplo, use "Enviar" en vez de un genrico "Aceptar".
Errores
Cuando se produzca un error al rellenar el formulario proporcione en la parte superior del mismo, y con suficiente contraste, un listado de los errores. Por cada error indique qu campo lo ha provocado, por qu motivo, cmo solucionarlo. Destaque los campos que han dado error pero no se base para ello nicamente en el color. Repita el mensaje de error al lado del campo para no tener que volver a la lista inicial para saber qu error lo provoc, precedido de la palabra "Error" en negrita. Cuando se produzca un error, el formulario no debe resetearse, es decir, todos los campos (errneos o no) deben seguir manteniendo la informacin en ellos introducida por el usuario. Redactar claramente los mensajes de error mediante trminos claros, sencillos y no tcnicos. No utilizar mensajes genricos del tipo No se ha podido enviar el formulario.
Feedback
En cada paso incluya brevemente informacin de los pasos anteriores ingresada por el usuario. La informacin que l ingres le resultar ms familiar que los textos definidos a la hora de crear el formulario. Cuando el usuario enve el formulario, infrmele del resultado de su accin: indquele si se ha realizado correctamente, qu datos se han enviado, cmo puede ponerse en contacto con los responsables del sitio si ha habido problemas o para hacer un seguimiento del mismo, o cmo puede modificar los datos enviados.
Si el proceso de envo es lento, incluya en la pgina un mensaje de "enviando datos" y si fuera posible un indicador de avance. Cuando los datos efectivamente fueron enviados, cambie la pgina por la de confirmacin o si el tiempo es muy extenso, enve un email de confirmacin.
Respuesta
Informe a los usuarios por qu deben rellenar el formulario, cundo y a travs de qu medio recibirn una respuesta. Si es un formulario de contacto enve un email automtico confirmado que se ha recibido. Si es un formulario de contacto, asegrese de que existan los mecanismos necesarios para responder de forma rpida y adecuada al mismo.
Accesibilidad
Asocie explcitamente las etiquetas con sus controles mediante LABEL y su atributo "for". Compruebe que el tabulador permite acceder a todos los campos en el mismo orden que el visual. Mejore la experiencia del usuario mediante JavaScript y AJAX pero asegrese que el formulario funcione correctamente sin ellos. No establezca un lmite de tiempo demasiado pequeo (timeout de sesin, por ejemplo) para complementar el formulario.
Formularios extensos
Si los formularios son muy extensos la solucin no son las columnas, sino la divisin en pginas bien rotuladas que indiquen al usuario en qu paso est del proceso (por ejemplo Paso 3 de 4). Si el formulario se presenta en varias pginas hay que seguir la consigna "1 tema = 1 pgina". El usuario debe poder volver a los pasos anteriores. Siempre que sea viable, debe poder modificar libremente los datos ingresados.
No solicite informacin externa en medio del proceso mediante la abertura de una ventana nueva del navegador. Evite la utilizacin de pestaas para crear formularios de varias pginas
Captulo III
Accesibilidad Web
Captulo III Accesibilidad Web | 121
Accesibilidad Web
Acceso sin barreraspor Humberto Demarco
Fig. 1. Dibujado por Charles McCathieNevile, 1999
Es sabido que el mundo real y el virtual presentan infinidad de similitudes y diferencias. Es sabido tambin que cuando no vivimos personalmente alguna situacin limitante, nos cuesta ponernos en el lugar de otras personas que si conviven a diario con ellas. No todos los interesados cuentan con las mismas posibilidades a la hora de pretender acceder a un sitio o portal de Internet. Hace unos das atrs, una persona me cont la experiencia que tuvo que vivir una amiga de ella, que sufri un accidente de trnsito y por ello adquiri una discapacidad motriz a partir de ese momento.
122 | Captulo III Accesibilidad Web
Esta situacin imposible de predecir, determin que a partir de ese momento, esta joven y su familia se vieran obligados a mudarse de su casa de dos plantas a otra de una sola. Las escaleras y las puertas angostas constituyeron solamente algunos de los ejemplos de las insalvables barreras existentes, que obligaron a esta familia a tener que mudarse de un sitio al que antes consideraban ideal. Se preguntar usted que tiene que ver este suceso con la accesibilidad de los sitios Web. Tambin en el mundo virtual se presentan diferentes barreras que impiden que personas con diferentes discapacidades, puedan disfrutar en igualdad de condiciones de todo el valioso material que Internet nos ofrece. Por ejemplo, las personas con discapacidad visual o auditiva se ven limitadas notoriamente en su accionar. El colectivo de las personas con discapacidad conforma aproximadamente un 10 % de la poblacin, tanto a nivel local como internacional, conformando un potencial mercado de usuarios y consumidores de los ms variados productos y servicios. Hoy en da, el concepto de Diseo Universal es el que aporta mayores beneficios a todas las partes, ya que segn sus premisas, todo producto, entorno o servicio, debe ser concebido desde su nacimiento de manera que el mismo pueda ser usado por todo tipo de personas: nios, jvenes, adultos, personas mayores, mujeres embarazadas, personas con discapacidad, etc.. Por lo expuesto, resulta importante dotar de accesibilidad a los portales estatales, para democratizar el acceso a la informacin. Estamos convencidos de que las principales barreras no son las arquitectnicas o las de un sitio Web, sino que son las barreras mentales las que nos impiden avanzar ms rpido para poder lograr beneficiar a todas y todos por igual.
Introduccin
Este captulo ofrece un resumen que permita a los responsables de sitios Web, administradores de contenidos o personal tcnico relacionado con el desarrollo y mantenimiento de sitios Web entender, implementar o buscar estrategias para implementar accesibilidad en los sitios Web del estado. Las recomendaciones y pautas aqu desarrolladas corresponden a un resumen de los lineamientos desarrollados por W3C, y en particular por la WAI12 (Grupo de trabajo especializado en el tema) y pretenden ser un punto de partida para lograr la accesibilidad en los sitios Web del estado Uruguayo. Para crear este documento se han investigado las mejores prcticas difundidas por diferentes organizaciones, tales como W3C, el comit de Normas del Gobierno de Chile, e INTECO entre otras, las cuales las encontrar detallada en las Referencias.
Qu se entiende por Accesibilidad?

Accesibilidad La accesibilidad es el grado en el que todas las personas pueden utilizar un objeto, visitar un lugar o acceder a un servicio, independientemente de sus capacidades tcnicas o fsicas.
Accesibilidad Web La accesibilidad Web se refiere a la capacidad de acceso a la Web y a sus contenidos por todas las personas independientemente de la discapacidad (fsica o tcnica) que presenten o de las que se deriven del contexto de uso (tecnolgicas o ambientales).
Realizar un diseo accesible va a permitir que una mayor cantidad de personas puedan percibir, entender, navegar e interactuar de forma efectiva con la Web, as como crear y aportar contenido. DISEO PARA TODOS
WAI Web Accessibility Initiative o Iniciativa para la Accesibilidad Web. Es una rama del World Wide Web Consortium que vela por la accesibilidad de la Web. Ver Anexo I Pautas, directrices y Buenas prcticas disponibles
12
La accesibilidad como un derecho

Las Naciones Unidas aprobaron el 20 de diciembre de 1993 las "Normas Uniformes sobre la igualdad de oportunidades para las personas con discapacidad", cuya finalidad es garantizar que nias y nios, mujeres y hombres con discapacidad, en su calidad de miembros de sus respectivas sociedades, puedan tener los mismos derechos y obligaciones que los dems. El fundamento poltico y moral de estas normas se encuentra en la "Carta Internacional de Derechos Humanos". El artculo 5, Posibilidades de acceso, en esta norma declara que los Estados deben reconocer la importancia global de las posibilidades de acceso dentro del proceso de lograr la igualdad de oportunidades en todas las esferas de la sociedad. Para las personas con discapacidades de cualquier ndole, los Estados deben (a) establecer programas de accin para que el entorno fsico sea accesible y (b) adoptar medidas para garantizar el acceso a la informacin y la comunicacin.
La accesibilidad como un principio de Gobierno Electrnico en Uruguay

Desde su propia concepcin, el Gobierno Electrnico avanza en el uso de las tecnologas con la finalidad de construir una Administracin Pblica enfocada en el ciudadano, siempre accesible y ms cercana. La Administracin Pblica deber garantizar la accesibilidad a la informacin y a los servicios por medios electrnicos de manera segura y comprensible, con especial nfasis en el cuidado del acceso universal y su adecuacin a mltiples soportes, canales y entornos, con el objetivo de que todas las personas puedan ejercer sus derechos en igualdad de condiciones. El uso de las Tecnologas de la Informacin y la Comunicacin posibilita la transformacin gradual de la forma y contenido de las relaciones de los ciudadanos con el gobierno, ubicando a las TIC como una herramienta fundamental para facilitar al ciudadano su relacin con la Administracin Pblica. En particular los portales del estado son un recurso muy importante para la comunicacin, difusin y prestacin de servicios de gobierno, lograr que estos sean accesibles ser un paso muy importante hacia un acceso equitativo y en igualdad de oportunidades para las personas.
Accesibilidad en los portales del Estado

Sus beneficios
Una pgina Web accesible puede aumentar la participacin de las personas con discapacidad, por brindar la capacidad de percibir, entender, navegar e interactuar. Si bien el principal objetivo de accesibilidad son las personas con discapacidad, tambin beneficia a las personas con discapacidades temporales, o sin discapacidad, en particular: las personas mayores que han visto disminuidas sus habilidad a consecuencia de la edad, las personas con bajo nivel de alfabetizacin o no habla el idioma, las personas con conexiones de bajo ancho de banda o la utilizacin de tecnologas ms antiguas, a los usuarios nuevos y poco frecuentes, a usuarios que operen en contextos muy diferentes de los ideales, que no sean capaces de ver u or, leer o entender texto, usar un teclado o ratn, o hablar con claridad, a usuarios que puede ser que no tengan discapacidades pero tengan los ojos ocupados o las manos ocupadas, ambiente ruidoso o necesidad de silencio, ancho de banda estrecho o tamao de pantalla o colores limitados.
Incorporar polticas de Accesibilidad en los portales del Estado facilitar el acceso a los sitios de gobierno, apoyar las iniciativas de inclusin de grupos de discapacitados, potenciar el teletrabajo, mejorar la velocidad de navegacin y facilitar el acceso con independencia de los dispositivos que se utilicen.
Diseo para todos

El propsito del diseo universal es simplificar la realizacin de las tareas cotidianas mediante la construccin de productos, servicios y entornos ms sencillos de usar por todas las personas y sin esfuerzo alguno. Est basado en 7 principios: Igualdad de uso: El diseo debe ser fcil de usar y adecuado para todas las personas independientemente de sus capacidades y habilidades. Flexibilidad: El diseo debe poder adecuarse a un amplio rango de preferencias y habilidades individuales. Simple e intuitivo: El diseo debe ser fcil de entender independientemente de la experiencia, los conocimientos, las habilidades o el nivel de concentracin del usuario. Informacin fcil de percibir: El diseo debe ser capaz de intercambiar informacin con usuario, independientemente de las condiciones ambientales o las capacidades sensoriales del mismo. Tolerante a errores: El diseo debe minimizar las acciones accidentales o fortuitas que puedan tener consecuencias fatales o no deseadas. Escaso esfuerzo fsico: El diseo debe poder ser usado eficazmente y con el mnimo esfuerzo posible.
Dimensiones apropiadas: Los tamaos y espacios deben ser apropiados para el alcance, manipulacin y uso por parte del usuario, independientemente de su tamao, posicin y movilidad.
Fuente: Fundacin Sidar - Acceso Universal Seminario SIDAR Pgina: http://www.sidar.org/recur/desdi/usable/dudt.php
Cmo lograr que el sitio Web sea accesible

Es difcil crear pginas Web accesibles? No ms que hacerla inaccesible, solamente exige que los equipos de desarrollo de portales, las herramientas de administracin de contenidos y los equipos de edicin de contenidos estn preparados para hacerlo. Lo importante es tenerlo en cuenta desde el inicio del proyecto de desarrollo del portal, como un requerimiento ms.
Principales aspectos a tener en cuenta

A la hora de construir un sitio Web accesible es necesario tener en cuenta varios aspectos importantes: 1. Fijar el objetivo de accesibilidad a alcanzar y determinar la poltica de accesibilidad del sitio.
2. La herramienta que utilizar para el desarrollo del portal: a. La herramientas de administracin de contenidos que utilizar para la creacin o transformacin de su portal, permitir cumplir con las pautas de accesibilidad? b. Si no utiliza una herramienta de administracin de contenidos, porque su sitio es programado por el equipo de desarrollo, estos tcnicos debern entender los cambios que deben implementar en sus desarrollos y las pautas que deben seguir.
3. Los contenidos y su estructuracin: a. Cuando planifique su contenido, debe lograr disponer de todo el texto del sitio independiente de la presentacin visual. b. Para estructurar dicho contenido es necesario utilizar elementos bsicos como: encabezados, listas, prrafos, tablas de datos, etc.. Estos elementos dan valor semntico a los contenidos y no deben utilizarse como elementos para disear. Por ejemplo: no utilizar una tabla para colocar mrgenes. c. Cuando transforme esos contenidos a lenguaje Web debe seguir los estndares publicados de manera de garantizar la compatibilidad. d. Si al estructurar los contenidos tiene la necesidad de incorporar otros elementos diferentes al texto, tales como: imgenes (fotos, grficos, logotipos, etc.), videos, audio, etc.. debe planificar la incorporacin de alternativas accesibles para cada uno de ellos. 4. La presentacin y maquetacin: a. Uno de los puntos importantes para lograr accesibilidad, es separar los contenidos de la presentacin. El contenido no debe depender de los estilos y la esttica que se utilice para mostrarlo. Una pgina Web debe poder ser entendida de igual modo si se accede a travs de un navegador tradicional, de un telfono mvil, de un lector de pantalla etc.. b. Despus que estructur los contenidos se debe incorporar la presentacin, intentando que sea con estilos uniformes, que facilite el aprendizaje, la lectura y la navegacin de todos los usuarios. c. Se recomienda no usar tablas de datos para la organizacin de la presentacin de los contenidos, ya que esto dificulta la comprensin del sitio para los usuarios que navegan utilizando por ejemplo un lector de pantalla. Utilice hojas de estilos en cascada (CSS). 5. Comprobar el nivel de accesibilidad logrado a. Una vez que finaliz el proceso de desarrollo del sitio Web es necesario comprobar que cumple con los requisitos de accesibilidad que se planificaron, para ello deber: i. Verificar que el contenido integro es entendible, que utiliz un lenguaje claro y sencillos que le permite alcanzar al mayor nmero de usuarios posibles.
ii. Utilizar un lector de pantalla para navegar el sitio, de forma de comprobar que es posible acceder a toda la informacin del sitio sin perder funcionalidades ni informacin. iii. Utilizar una herramienta de validacin que le permita verificar el nivel de accesibilidad alcanzado y rastrear errores. Ver Herramientas de validacin. 6. Publicacin de los contenidos a. Definir procedimientos claros de publicacin y control de calidad que permita garantizar los criterios de accesibilidad adoptados para cada uno de los contenidos que sern publicados una vez realizada la puesta en produccin del sitio b. En esta etapa es fundamental la concientizacin y la capacitacin a cada uno de los editores de contenidos en la forma de redactar, la inclusin de descripciones adecuadas en las imgenes y los elementos multimedia.
Criterios de Accesibilidad para los portales de Gobierno

Para lograr desarrollar pginas con contenidos accesibles, deber seguir las directrices establecidas en Las Pautas de Accesibilidad de Contenido Web (WCAG 2.0) desarrolladas por W3C y adoptadas por AGESIC. Las pautas completas las puede encontrar en: http://www.codexexempla.org/traducciones/pautas-accesibilidadcontenido-Web-2.0.htm Estas pautas establecen que los sitios Web deben ser perceptibles, entendibles, operables y robustos. Estos cuatro principios engloban una serie de directrices que permiten mejorar y eliminar aquellos elementos que bloquean o interfieren el acceso a la Web, en particular a las personas con discapacidad. Segn los criterios y pautas que logre aplicar en su sitio Web es el nivel de accesibilidad. Estos son indicados como A, AA y AAA. Puede ocurrir que tengan accesibilidad parcial, dado que solo algunas pginas cumplen los requisitos. El objetivo es que los portales del Gobierno Uruguayo puedan alcanzar a corto plazo el nivel AA y aplicar buenas prcticas sugeridas en algunas de las pautas de tipo AAA.
Pautas
Perceptibles
Los usuarios deben ser capaces de percibir la informacin que se presenta en las pginas de su sitio Web (no puede ser invisible a todos sus sentidos).
Pauta 1.1 Alternativas textuales

Proporcione alternativas textuales para todo contenido no textual (imgenes, grficos, iconos, etc.), de manera que pueda ajustarse a las necesidades del usuario que est accediendo, como por ejemplo en una letra mayor, braille, voz, smbolos o un lenguaje ms simple. Las imgenes son un elemento fundamental en todo contenido Web, as como los grficos, los iconos, los smbolos o cualquier representacin grfica. Todos estos elementos deben disponer de una descripcin o texto alternativo que transmita la informacin a aquellas personas que no puedan percibirla.
Criterio 1.1.1. Contenido no textual Nivel A Recomendaciones Colocar en todas las imgenes, o botones de imagen de los formularios y las zonas activas de los mapas de imagen un texto alternativo adecuado.
<A href="javascript:ADDFont('s');"><IMG height="16" hspace="5" src="/Images/08/Iconos/icn_zoom_out.gif" alt=" | achicar texto | " width="16"></A> Para aquellos casos individuales donde no estn disponibles los grficos, si se usan navegadores de slo texto con imposibilidad de mostrar imgenes, recursos limitados de Internet, o aquellas personas que navegan por la Web con la opcin de mostrar grficos desconectada, el atributo alt ofrece una estupenda forma de escribir una visin natural de lo que es la imagen. La descripcin de alt aparecer antes de que se cargue el archivo asociado. Esta es una manera de mantener informados a los navegantes de lo que posteriormente vern. Las descripciones definidas con este atributo tambin aparecen cuando el puntero del
Criterio
Nivel
Recomendaciones ratn pasa por encima de la imagen. En las imgenes que no transmitan contenidos porque son decorativas, o fondos de imagen o que disponen de textos como contenido principal, colocar la cadena vaca como alternativa: alt = Colocar nombres descriptivos (value) en los botones de los formularios. Colocar etiquetas asociadas a los elementos de los formularios (label) y sino fuera posible un (title). Identificar mediante textos accesibles todos los elementos multimedias incrustados. Colocar ttulo apropiados a los marcos (frames).
Ejemplo
En la Pgina del Ayuntamiento de Villamayor en Espaa (cumple con el nivel AAA) podemos encontrar ejemplos para esta pauta. http://www.aytovillamayor.es/ayuntamiento/index.php Al pasar sobre la foto que aparece en la pgina se despliega un mensaje describiendo el ttulo de la foto, adems de tener un texto alternativo que permite que un navegador de ciegos pueda describir el contenido. Y como complemento sobre el lado derecho de la foto existe un texto que realiza un resumen de la informacin a la que se acceder.
De esta forma los navegadores de ciegos u otros dispositivos de lectura podrn describir el contenido o con el objetivo de facilitar el entendimiento de esa imagen. Esto no es necesario si las imgenes forman parte del diseo (logotipo, decoracin, etc.) y no del contenido, por lo cual no son elementos fundamentales para entender la informacin difundida.
Pauta 1.2 Contenido multimedia dependiente del tiempo

Proporcione alternativas sincronizadas para contenidos multimedia dependientes del tiempo. El trmino multimedia hace referencia a los contenidos que se presentan como audio, video, animaciones o presentaciones interactivas y cuando hablamos de alternativas hacemos referencias a transcripciones, subttulos, audio descripciones o cualquier alternativa que pueda tornar accesible ese tipo de contenido. Existen varias alternativas, que podr usar dependiendo de la situacin y posibilidades tcnicas que disponga.
Criterio 1.2.1. Contenidos de solo audio o solo video pregrabados
Nivel A
Recomendaciones Colocar texto alternativo que los describa y en los casos que sea posible colocar la transcripcin completa del audio o el video.
Ejemplo
Suponga que debe colocar el audio de una entrevista realizada a uno de sus funcionarios en la radio, como una noticia en su portal. Siguiendo esta pauta debe: Colocar en el texto alternativo : Audio de entrevista y en la descripcin: Archivo de audio de la entrevista realizada en la FM 10.23 al Sr Juan Gonzlez Colocar como contenido alternativo la transcripcin de la entrevista en formato de texto.
Criterio 1.2.2. Subttulos en los contenidos de video pregrabados
Nivel A
Recomendaciones Otra alternativa es colocar subttulos en los materiales multimedia a publicar. Excepto si el material fue colocado como alternativa al texto.
1.2.3. Audiodescripcin al video o contenidos media alternativos.
Colocar una transcripcin o audiodescripcin a los videos pregrabados. Esto permite que una persona no vidente al seleccionar ese contenido pueda escuchar una descripcin del contexto y lo que est sucediendo.
Ejemplo
Suponga que desea colocar un video promocin de un nuevo producto como contenido de su portal. Aunque el contenido tiene audio quizs este no es suficiente para entender el contexto en el que se est desarrollando. Para que este contenido sea accesible deber grabar una descripcin sincronizada con el video que vaya explicando lo que est sucediendo: Entro una persona de unos 60 aos caminando lentamente con bastn. Esta descripcin en audio le permite al usuario entender de otra forma lo que est sucediendo. Nota: Esto no es necesario si el contenido principal est en texto y el video es solo complemento. En caso de proporcionar una alternativa textual en lugar de la audiodescripcin esta debe consistir en una descripcin completa del contenido, tanto visual como auditivo, escenarios, expresiones, gestos, dilogos etc. como si se tratase de un guin. 1.2.4 Subttulos a los archivos de audio en directo: AA Proporcione subttulos sincronizado para los contenidos de audio en directo. Esto siempre y cuando no hay realizado una transcripcin completa del audio o lenguaje de seas.
1.2.5 Audio descripcin en los
AA
Proporcione una audiodescripcin para todos los vdeos pregrabados que publique en su portal. Esta opcin es similar al criterio 1.2.3, salvo que no acepta la opcin de
Criterio
videos
Nivel
Recomendaciones proporcionar una alternativa en forma de descripcin. Solo acepta la opcin de audio descripcin. Esto es un nivel de exigencia ms alto ya que exige si o si una audio descripcin. Esto beneficia a las personas que son ciegos o tienen baja visin, a las personas con limitaciones cognitivas que tienen dificultades para interpretar visualmente lo que est sucediendo. En paralelo al video se van describiendo las situaciones, contexto, imgenes, actitudes, sensaciones, etc.
Ejemplo
Suponga que desea colocar el video de una capacitacin sobre las aves en Uruguay. Que debera colocar: Ttulo: "Evolucin de las Aves en Uruguay por el profesor Anbal Gonzlez. Descriptor: Un profesor muestra fotografas de las aves con largos, delgados picos. El profesor dice: "Estas fotos fueron tomadas en las Sierras de Minas".
1.2.6 Interpretacin con Lengua de seas: 1.2.7 Audio descripcin extendida (pregrabada):
AAA
Proporcionar una interpretacin a lengua de seas sincronizada con el contenido de audio pregrabado.
AAA
Cuando las pausas del audio en un vdeo son insuficientes para permitir que la audiodescripcin transmita el sentido del vdeo, se proporciona una audio descripcin extendida para todo contenido de vdeo. Esto implicar que el video tenga pausa por partes para que la audio descripcin pueda correr.
Ejemplo
Video de una conferencia. Un profesor de fsica est dando una conferencia. Hace libremente bocetos sobre la pizarra, hablando rpidamente como l seala. Tan pronto como ha terminado de discutir un problema, borra el dibujo y hace otro dibujo sin dejar de
Criterio
Nivel
Recomendaciones hablar y hacer gestos con la otra mano. Para lograr que este contenido sea accesible ser necesario contar con pausas en el video y en esas pausas ampliar el video con una audio descripcin: El profesor realiz un esquema donde dibuj una pelota, una curva Finalizada la audio descripcin el video reanuda. Importante: Cuando se habla de alternativas textuales, no necesariamente debe ser resuelto siempre en html, puede cualquier alternativa textual accesible.
Pauta 1.3 Adaptabilidad

Cree contenidos que puedan presentarse de diversas maneras (como por ejemplo una composicin ms simple) sin perder la informacin ni su estructura al adaptarse a otras modalidades y tecnologas. Esta pauta es importante a la hora de maquetar sus pginas y una de las recomendaciones es: utilice hojas de estilo.
Criterio
1.3.1 Informacin y relaciones
Nivel A
Recomendaciones La informacin, la estructura y las relaciones transmitidas a travs de la presentacin pueden ser determinadas a travs de programacin, o se encuentran disponibles en formato de texto. Cuando hablamos que pueda ser determinado por programacin, hacemos referencia a que pueda ser ledo e interpretado independientemente del dispositivo y el formato. Para lograr esto deber usar marcado semntico: Al colocar contenidos de textos se deber utilizar la estructura correcta, de manera que pueda ser ledo e interpretado independientemente del formato. Para eso deber designar encabezados con <h1>, listas con <ul>,<ol> y <dl>, texto enfatizado con <strong>, <code>,<aabbr>,<blockquote>. Las tablas se usarn para marcar datos tabulados. Las celdas de datos <td> se deben asociar con los encabezados <th> donde sea necesario. Se identificarn ttulos de las tablas (caption) y sus resmenes (summary). Asociar las etiquetas (label) con sus campos correspondientes (input) dentro de un formulario. Los elementos de los formularios que estn relacionados agruparlos mediantes fieldset/legend.
Ejemplo
Un formulario en el que el usuario deba ingresar datos y se indiquen con * los campos obligatorios puede ser interpretado por programacin. En caso que no pueda hacerse se puede agregar un texto descriptivo. Por ejemplo, "todos los campos obligatorios estn marcados con un asterisco (*)". El texto debe estar cerca de la
Criterio
Nivel
Recomendaciones descripcin de la informacin que se describe, como elemento en la matriz o en el elemento adyacente. Un texto con formato de espacio interlineal doble, o con lneas en blanco antes de cada ttulo, con vietas delante de las listas de tems, son convenciones que pueden ser determinadas por programacin.
1.3.2 Secuencia significativa.
Cuando la secuencia en la que se presenta un contenido afecta a su significado, este deber ser presentado en un orden lgico e intuitivo. La secuencia correcta de navegacin y lectura puede ser determinada por el orden del cdigo fuente.
Ejemplo
El caso tpico es cuando tenemos que presentar el contenido en una tabla. Se deber identificar cuales son las celdas de encabezado y el orden de lectura, de manera que pueda ser leda por otros dispositivos sin perder el significado. Ejemplo: En un contenido que est organizado en varias columnas, respetar una presentacin lineal del contenido de manera de que los datos puedan ser ledos de arriba hacia abajo en la columna y luego a la prxima. 1.3.3 Caractersticas sensoriales. A Las instrucciones que se proporcionan para comprender y operar con un contenido no deben estar relacionadas nicamente con las caractersticas sensoriales de los componentes, tales como forma, tamao, ubicacin visual, orientacin o sonido.
Ejemplo
Suponga que para dar una instruccin en un portal indica: haga clic en la flecha roja. La flecha roja puede no percibirse por determinados usuarios. Para hacer que este contenido sea accesible deber presentar alternativas que no dependan del color, con lo cual debera acompaar la instruccin con una indicacin textual tal como: haga clic o seleccione la opcin Avanzar (que se relaciona en el diseo con la flecha roja).
Ejemplo
Criterio
Nivel
Recomendaciones En un contenido que tiene un instructivo no colocar por ejemplo: las instrucciones estn en la columna derecha, podra colocar las instrucciones se encuentran en la seccin Pasos a seguir.
Pauta 1.4 Distinguible

Facilite a los usuarios ver, escuchar el contenido y distinguir la separacin entre primer plano y fondo.
Criterio 1.4.1 Empleo del color: Nivel A Recomendaciones No utilice el color como el nico medio visual para transmitir una informacin, indicar una accin, provocar una respuesta o distinguir visualmente un elemento.
Ejemplo
Campos de un formulario Si desea utilizar un formulario que contiene campos requeridos, no los distinga nicamente por un cambio de color, agregue un icono con texto alternativo Requerido. Adems incorpore en la parte superior del formulario la explicacin correspondiente: Los campos obligatorios estn marcados con rojo y con un icono cuyo texto alternativo dice Requerido. Estas dos opciones pueden ser por interpretadas por otras tecnologas. Indicar una accin Una accin en la que le dice Haga clic en el botn verde, debera cambiar la propuesta por Haga clic en la opcin Avanzar, donde la opcin Avanzar se encuentra descripta en un botn de color verde. Pero el color no es la nica forma de identificar la accin. Distinguir vnculos Los enlaces deben distinguirse de los elementos y texto que los rodea, no utilice un cambio de color, use otra forma de distinguirlos como por ejemplo subrayarlos cuando reciben el enfoque.
Criterio
Nivel
Recomendaciones Nota: Este criterio de xito trata especficamente acerca de la percepcin del color. Otras formas de percepcin se cubren en la Pauta 1.3, que incluye el acceso programado al color y a otros cdigos de presentacin visual.
1.4.2 Control de audio
Si cualquier audio se reproduce automticamente en una pgina Web durante ms de tres segundos debe existir un mecanismo que permita pausar o detener el audio, o un mecanismo que permita controlar el volumen del audio de manera independiente al del resto del sistema. De manera que no interfiera por ejemplo con un lector de pantalla.
1.4.3 Contraste (mnimo)
AA
La presentacin visual del texto y las imgenes de texto tienen una relacin de contraste de al menos 4.5:1, excepto para los siguientes casos: Gran tamao: El texto a gran tamao (de ms de 18 puntos o 14 puntos en negrita) y las imgenes de texto a gran tamao tienen una relacin de contraste de al menos 3:1. Incidental: El texto o las imgenes de texto que son parte de un componente de interfaz de usuario inactivo o que son decoracin, que no son visibles para nadie o que son parte de una imagen cuyo contenido significativo es otro contenido visual, no tienen un requisito mnimo de contraste. Logotipos: El texto que es parte de un logo o de un nombre de marca no tiene un requisito mnimo de contraste.
1.4.4 Variar el tamao de texto
AA
Debe ser posible variar el tamao del texto hasta un 200% sin necesidad de emplear tecnologa de apoyo. Al variar el tamao del texto no se deben perder contenidos ni funcionalidades. Es posible utilizar botones para ampliar la fuente u ofrecer diferentes versiones de las hojas de estilo. Una tcnica aceptada tambin es el uso de unidades de medidas relativas em. Las unidades de longitud consisten en un nmero seguido de una unidad de medida (cm, em, in, pt, px). Hay dos tipos de unidades: absolutas (pulgadas (in) una pulgada=2.54 cm, centmetros (cm), milmetros (mm), puntos
Criterio
Nivel
Recomendaciones (pt)- un punto=1/72 de pulgada, picas (pc) - una pica=12 puntos) y relativas (em, px, ex). La unidad 'em' puede utilizarse para cualquier propiedad CSS que admita medidas (mrgenes, sangras, etc.) lo que permite un diseo proporcionado al sistema del usuario. Lo importante es que la pgina debe ser legible y funcional cuando se doble el tamao del texto.
1.4.5 Imgenes de texto.
AA
Es preferible utilizar texto para transmitir informacin que imgenes de texto, excepto para los siguientes casos: La imagen de texto puede ser visualmente personalizada segn los requisitos del usuario; La presentacin de un texto en particular es esencial para la informacin que se est transmitiendo. Nota: Los logotipos (textos que son parte de un logo o de un nombre de marca) se consideran esenciales.
1.4.6 Contraste (aumentado)
AAA
La presentacin visual del texto y las imgenes de texto tienen una relacin de contraste de al menos 7:1 excepto para los casos mencionados en el punto 1.4.3.
1.4.7 Bajo o sin sonido de fondo
AAA
Compruebe que no hay un sonido de fondo o si existe es muy bajo tal que permite distinguir fcilmente las conversaciones.
1.4.8 Presentacin Visual
AAA
Para bloques de texto de ms de una frase de longitud: No deben existir ms de 80 caracteres de ancho No estarn justificados a ambos lados Tendrn un interlineado de al menos la mitad de la altura del texto y un espacio entre prrafos de 1,5 veces la medida del interlineado. Tendrn especificados un color de primer plano y fondo. No aparecer desplazamiento horizontal cuando se doble el tamao del texto.
Criterio 1.4.9 Imgenes de texto sin excepcin
Nivel AAA
Recomendaciones Solo se utilizarn imgenes de texto para decorar cuando no transmitan informacin o no se pueda presentar de otra forma como por ejemplo un logotipo.
Operable
La interfaz de usuario y sus componentes de navegacin deben ser operables, deben permitir interaccin con ellos. No puede existir un control o componente que no pueda accionarse por los usuarios.
Pauta 2.1 Accesible a travs del teclado

Haga que todas las funcionalidades estn disponibles a travs del teclado.
Criterio 2.1.1 Teclado. Nivel A Recomendaciones Toda funcionalidad del contenido debe ser accesible mediante teclado y de forma independiente del tiempo, salvo aquellas que no pueden ser realizadas como por ejemplo un dibujo a mano alzada. No obstante se puede proveer de otra interfaz como el mouse para acceder a las funcionalidades. Si usa atajos de teclado no deben entrar en conflicto con las del navegador y/o el lector de pantalla.
2.1.2 Sin trampa de teclado o teclado no bloqueado:
El foco del teclado debe poder moverse para todos los elementos de navegacin de la pgina. El foco debe poder moverse hacia un componente de la pgina y fuera de este por medio de teclado u otro mtodo de salida estndar. En caso que el usuario deba usar otro mtodo para moverse debe estar indicado explcitamente.
Pauta 2.2 Tiempo suficiente

Proporcione a los usuarios el tiempo suficiente para leer y usar un contenido.
Criterio 2.2.1 Lmite de tiempo ajustable Nivel A Recomendaciones Si la pgina o aplicacin tiene un lmite de tiempo debe permitir que los usuarios puedan completar la tarea. Para eso deber disponer de opciones que permitan apagar, ajustar o aumentar el tiempo lmite. Permita al usuario realizar al menos una de estas tareas: Desactivar: Al usuario se le permite desactivar el lmite de tiempo antes de encontrarse con l o, Ajustar: Al usuario se le permite ajustar el lmite de tiempo antes de encontrarse con l, hasta un rango de al menos diez veces la duracin por defecto o, Extender: Al usuario se le avisa antes de que el lmite expire con un margen de la menos 20 segundos y se le permite extender ese mismo lmite por medio de alguna accin simple (por ejemplo, "pulse la barra espaciadora"), y adems se le permite repetir la accin al menos diez veces o Se consideran excepciones, cuando la tarea requiere el lmite de tiempo, por ejemplo una subasta en lnea o un examen, o cuando el lmite necesario supera Excepcin de tiempo real: El lmite de tiempo es un requisito de un evento en tiempo real (por ejemplo, una subasta) y no es posible ninguna alternativa a ese lmite o Excepcin esencial: El lmite de tiempo es esencial y su extensin invalidara la actividad o Excepcin de 20 horas: El lmite de tiempo supera las 20 horas. 2.2.2 Pausar, detener, ocultar A Para cualquier informacin que comience automticamente y que se mueva, parpadee, se desplace o se actualice automticamente y se presente en paralelo a otro contenido, se debe proporcionar un mecanismo para pausarlo, detenerlo u ocultarlo a menos que este efecto forme parte de una actividad esencial para transmitir
Criterio
Nivel
Recomendaciones informacin. El usuario debe poder controlar manualmente los tiempos cuando tiene por ejemplo una pgina de recarga o re-direccionada automticamente, la actualizacin de un campo mediante AJAX o un aviso, etc.
Pauta 2.3 Ataques

No disee un contenido de manera que se sepa que puede causar ataques epilpticos. Evite los cambios bruscos de luminosidad y destellos en la pantalla.
Criterio 2.3.1 Tres destellos o debajo del umbral Nivel A Recomendaciones No debe existir ningn contenido que produzca ms de tres destellos en cualquier perodo de un segundo, a menos que estos destellos ocupen un rea inferior al 25% de un campo visual de 10 a una distancia normal de trabajo, o sean de bajo contraste y no contenga demasiado rojo. 2.3.2 Tres detalles AAA No deber crear ningn contenido que destelle ms de 3 veces por segundo
Pauta 2.4 Navegable

Proporcione medios que sirvan de ayuda a los usuarios a la hora de navegar, localizar contenido y determinar dnde se encuentran.
Criterio 2.4.1 Saltar bloques o accesos directos. Nivel A Recomendaciones Existe un mecanismo que permite saltar bloques de contenido que se repiten en mltiples pginas Web. Cuando se repitan elementos en todas las pginas asegrese de colocar enlaces que permitan avanzar a otros contenidos, ejemplo: Ir a tema principal
Ejemplo
Observe la pgina de W3C en la zona de arriba a la derecha el enlace Skip
2.4.2 Ttulo en las pginas:
Las pginas Web deben tener un ttulo que describa e informe su tema o propsito.
2.4.3 Orden de foco
Los componentes de su pgina deben recibir el foco en un orden que permita navegar secuencialmente y con un orden lgico e intuitivo.
2.4.4 Propsito de un vnculo (en su contexto):
Los vnculos o enlaces que coloque en las pginas deben tener una descripcin lo suficientemente clara para identificar su propsito. Esta descripcin puede estar directamente en el enlace o en los prrafos que lo rodean.
Ejemplo
Suponga que junto al icono de un archivo coloca el vnculo para descargar una manual. Observe las dos soluciones:
Criterio
Nivel
Recomendaciones Opcin1: Haga clic aqu Opcin mejorada: Descargar manual completo Los enlaces o botones de un formulario que tengan el mismo destino o propsito deben tener siempre la misma descripcin.
2.4.5 Mltiples medios
AA
En la etapa de diseo de los bocetos o wireframes tenga en cuenta que debe ofrecer varias formas de encontrar las pginas en el sitio.
Ejemplo
Colocar una lista de pginas relacionadas, tablas de contenido, mapa del sitio, disponer de un buscador, disponer de diferentes categorizaciones por los cuales acceder al contenido. Esto no se aplica para los resultados de una bsqueda. 2.4.6 Encabezados y etiquetas AA Los encabezados y las etiquetas de las pginas deben describir el tema o propsito. Esto se aplica tanto a las etiquetas en los controles de los formularios como a los encabezados que desea utilizar dentro de una pgina. En este ltimo caso busca dotar de una secuencia lgica al texto.
Ejemplo
Cometidos
Cometidos sustantivos Proponer y asesorar al Poder Ejecutivo en la formulacin de polticas en materia de la Sociedad de la Informacin y en el desarrollo informtico del Estado. Cometidos de apoyo a los sustantivos Gerenciar los recursos humanos, materiales y financieros. La seccin de encabezados est clara y concisa y la estructura de la informacin est reflejada en la estructura de los encabezados
Criterio 2.4.7 Foco visible
Nivel AAA
Recomendaciones Deben distinguirse claramente el foco actual del teclado. Esto deber comprobarlo visualmente, observando cmo se desplaza el foco al utilizar el tabulador sobre la pgina donde se encuentra.
2.4.8 Ubicacin
AAA
Proporcionar al usuario informacin de orientacin sobre su ubicacin dentro de una coleccin de pginas Web.
Ejemplo
Utilice un camino de migas (rastro o bredcrumbs en ingls)
usuario.
Ejemplo
Especifique la secuencia de pasos en la que se encuentra el
Paso 3 de 5 Seleccione los productos a comprar
2.4.9 Propsito de los vnculos
AAA
Este criterio se aplica solo a los vnculos. Debe identificar el propsito de cada vnculo por medio exclusivo del texto del propio vnculo. No debern existir enlaces con el mismo texto que vinculen a lugares diferentes. Ejemplo Leer ms
2.4.10 Encabezados de seccin
AAA
Utilizar encabezados de seccin para organizar los contenidos. Este criterio afecta a la forma de desarrollar los contenidos en cada pgina y como estructurarlos mejor, para lograr que sean fciles de leer.
Comprensible
La informacin y el funcionamiento de la interfaz de usuario debe ser comprensible, los usuarios deben ser capaces de comprender fcilmente la informacin y el funcionamiento de la interfaz.
Pauta 3.1 Legible

Haga el contenido textual legible y comprensible.
Criterio 3.1.1 Idioma de la pgina: Nivel A Recomendaciones Identifique el idioma de la pgina de manera que pueda ser detectado automticamente. Ejemplo <HTML lang=es> 3.1.2 Idioma de partes AA Si existen secciones que tienen contenidos en diferente idioma, identifquelo de manera que pueda ser detectado automticamente. Esto no se aplica si se trata de nombres propios, trminos tcnicos, palabras en un idioma indeterminado o frases propias de la lengua. 3.1.3 Palabras inusuales AAA Proporcione un mecanismo adicional para comprender palabras especficas, o palabras ambiguas o desconocidas o modismos. Utilice una lista de definiciones, un glosario de trminos o cualquier otro mtodo que permita comprender los trminos usados dentro de los contenidos.
3.1.4 Abreviaturas
AAA
Proporcione un mecanismo para identificar las abreviaturas desarrolladas o el significado de las abreviaturas. Ejemplo: AGESIC -> Agencia para el Desarrollo del Gobierno de Gestin Electrnica y la Sociedad del Conocimiento Puede usar el <abbr> o enlazar la abreviatura a un glosario de trminos la primera vez que se utilice el trmino, o describirlo en el mismo contenido.
3.1.5 Nivel de lectura
AAA
Al desarrollar los contenidos, cuando encuentre algunos texto ms complejos que requieran un nivel de lectura ms avanzado, proporcione una versin complementaria que no exija ms habilidad que la de una persona con nivel de educacin primaria
Criterio
Nivel
Recomendaciones de aproximadamente unos 9 aos.
3.1.6 Pronunciacin
AAA
Si dentro de un contenido utiliza una palabra que deba llegar una pronunciacin especfica para comprender su significado, proporcione la pronunciacin seguida a la palabra o mediante un vnculo a un glosario.
Pauta 3.2 Predecible

Cree pginas Web que aparezcan y se manejen de manera predecibles.
Criterio 3.2.1 Con foco:
Nivel A
Recomendaciones Recibir el foco por parte de cualquier componente no provoca ningn cambio de contexto.
3.2.2 Con entrada de datos:
Cambiar la configuracin de cualquier componente de la interfaz de usuario no causa automticamente ningn cambio de contexto a menos que el usuario haya sido advertido del comportamiento antes de emplear el componente.
3.2.3 Navegacin consistente:
Los mecanismos de navegacin repetidos en mltiples pginas Web dentro de una coleccin de pginas Web aparecen en el mismo orden relativo cada vez que se repiten, a menos que se d un cambio iniciado por el usuario.
3.2.4 Identificacin consistente:
Los componentes que tienen la misma funcionalidad dentro de una coleccin de pginas Web se identifican de forma consistente.
3.2.5 Cambio a peticin:
AAA
Los cambios de contexto se inician solo a peticin del usuario, o existe un mecanismo para desactivar tales cambios.
Pauta 3.3 Ayuda a la entrada de datos

Ayude a los usuarios a evitar y corregir los errores.
Criterio 3.3.1 Identificacin de errores Nivel A Recomendaciones Si ocurre un error al ingresar datos, identifique en que tem ocurri el error y describa claramente el error de manera de orientar al usuario donde ocurri y como solucionarlo fcilmente.
Ejemplo
En una pgina se solicita al usuario ingresar una serie de datos, nombre, apellido, fecha de nacimiento, etc. Al finalizar el ingreso se produce un error en la fecha de nacimiento. Podra aparecer el siguiente mensaje: La fecha ingresada no es correcta. Debe ingresar el dato respetando el siguiente formato: dd/mm/aaaa (dos dgitos para el da, dos dgitos para el mes y cuatro dgitos para el ao). Por ejemplo 23/09/2007. Vuelva a ingresarla y seleccione luego la opcin Enviar para completar la suscripcin correctamente.
Una forma de minimizar los errores es identificar los campos obligatorios en los formularios, incorporar ayudas textuales en un lenguaje simple de manera que el usuario pueda comprender el formato en el que debe ingresar, si existe limitacin de caracteres, el dato exacto que se solicita, etc.. 3.3.2 Instrucciones o etiquetas A Proporcione etiquetas suficientes, avisos y todas las instrucciones que sean necesarias para que los usuarios utilicen correctamente elementos interactivos.
Ejemplo
Suponga que un usuario debe selecciona la suscripcin a una revista y el formulario que aparece es similar al siguiente:
Criterio
Nivel
Recomendaciones
Podra mejorarlo indicando en lugar de Modalidad de Suscripcin, Seleccione la modalidad de suscripcin deseada 3.3.3 Sugerencia tras error
AA
Si se detecta automticamente un error al ingresar los datos proporcionar las sugerencias al usuario para solucionar el problema en forma oportuna y accesible.
3.3.4 Prevencin de errores (legales, financieros, de datos):
AA
Si en sus pginas Web el usuario realizar transacciones econmicas, asumir compromisos legales que modifiquen o borren datos y enviar respuestas a algn tipo de preguntas, debe: Permitir que el envo sea reversible. Validar los datos ingresados y permitir corregirlos en caso de error.
Proporcione un mecanismo para que el usuario pueda verificar y aprobar los datos antes de finalizar el envo de la informacin.
3.3.5 Ayuda 3.3.6 Prevencin de errores (todo error):
AAA AAA
Proporcionar ayuda contextual. En las pginas Web que requieran que el usuario enve informacin sin importar de que tipo sea, cualquier accin debe poder ser reversible, la informacin debe poder ser verificada y/o confirmada.
Robusto
Su sitio Web y debe ser lo suficientemente robusto para permitir que perdure en el tiempo, que se mantenga accesible, que sea compatible con las tecnologas de ayuda que disponen usuarios discapacitados para acceder a la informacin. Este principio tiene una pauta.
Pauta 4.1 Compatible

Maximice la compatibilidad con agentes de usuario actuales y futuros, incluyendo los productos de apoyo.
Criterio 4.1.1 Interpretacin Nivel A Recomendaciones Para los contenidos que haya implementado usando HTML/XHTML verifique que los elementos cuentan con etiquetas completas de apertura y cierre, que se anidaron correctamente y que no tienen atributos duplicados. Para comprobarlo utilice el validador http://validator.w3.org.
4.1.2 Nombre, rol, valor
Este criterio est pensado para aquellos que desarrollan o programen su interfaz de usuario. Todo componente de la interfaz de usuario est correctamente determinado, el nombre, el rol y el valor puede ser interpretado por los navegadores, plugg-ins, reproductores multimedias, lectores de pantalla, magnificadores de pantalla, software de reconocimiento de voz, teclados alternativos, etc..
Ejemplo
Un estado importancia de un control de interfaz de usuario es si tiene o no tiene el foco. Otro ejemplo puede ser si una casilla de verificacin est seleccionada o no.
Comprobacin de la Accesibilidad Web

Existen diferentes herramientas para validar, en este captulo se presentarn las herramientas de acuerdo a dos categoras: Validacin de Gramtica y Validacin de la Accesibilidad. Las herramientas de validacin de gramtica sirven para comprobar que tanto las pginas con cdigo HTML como las hojas de estilo estn gramaticalmente bien formadas y son vlidas. Se recomienda utilizar las herramientas de validacin gramatical de cdigo proporcionadas por el W3C: Validador (X)HTML de W3C y Validador Hojas de Estilo en Cascada (CSS) de W3C.
Las herramientas de validacin de la accesibilidad sirven para identificar de manera automtica problemas de accesibilidad. Si bien son de ayuda en dicha evaluacin, las herramientas automticas no son infalibles y pueden considerar como error algo que en realidad no lo es, o por otra parte, detectar errores que el usuario debe revisar en forma manual. Se recomienda utilizar las herramientas de validacin de la accesibilidad: TAW (Test de Accesibilidad Web), Link Checker de W3C y W3C mobileOK Checker y AChecker (Web Accessibility Checker).
Evaluacin y Comprobacin Automtica

Validacin de Gramtica - Validador (X)HTML de W3C
Es un servicio online de validacin de cdigo del W3C (World Wide Web Consortium), el cual permite comprobar documentos Web. En general, los documentos Web estn desarrollados con lenguajes de marcas hipertextuales (HTML, (X)HTML, SMIL, MathML, SVG, DTD, SGML, XML, etc.) los cuales estn definidos por especificaciones tcnicas o reglas de gramtica del lenguaje. Comprobar un documento Web contra especificaciones tcnicas (estndares (X)HTML, gramticas del W3C, normas ISO (ISO 8879-(SGML), ISO/IEC 15445), etc.) se llama validacin y esto es lo que realiza esta herramienta. Un documento que pase este proceso con xito se toma como vlido.
Como accede a la herramienta

Se accede a la misma a travs de la Web oficial. http://validator.w3.org/ La versin actualmente disponible es la v0.8.5. y es gratuita
Servicio de Validacin del Lenguaje HTML- Markup Validation Service

Una vez que se accede al sitio Web oficial se presenta la siguiente pantalla, la cual contiene tres vistas que le permiten validar por la URL de la pgina, validar el archivo y validar el marcado completo de un contenido:
Validar por URL (Validate by URL)

Pasos a seguir:
Escriba en el campo Address (Direccin) la direccin de la pgina Web (URL) a validar y haga clic en el botn Check (Chequear). Puede utilizar Mas Opciones (More Options) para configurar alternativas en la herramienta.
Las casillas que se pueden activar o desactivar son: Character Encoding (Codificacin de Caracteres) La codificacin de caracteres es la traduccin del cdigo de computadora a texto legible y es utilizada en documentos HTML. El estndar Unicode (Unicode Industrial Standard) codifica caracteres usando diferentes esquemas llamados Formatos de Transformacin Unicode (UTF). El mas recomendado es el UTF-8, que es un set de caracteres de 8-bits de longitud variable el cual cuenta con una gran capacidad para representar todos los caracteres, siendo compatible con ASCII. Un documento HTML utilizando el set de caracteres UTF-8 debera contener una declaracin en su encabezado realizada mediante el tag HTML meta (<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">). Esta opcin permite anular la codificacin de caracteres de informacin del documento. Usted puede utilizar esta opcin con fines de prueba, pero es muy probable que el documento HTML deba ser asociado con su codificacin de caracteres, sino la herramienta de validacin determinar que el documento no es vlido. A modo de ejemplo, un mensaje sera: No Character Encoding Found! (Codificacin de Caracteres No Encontrado!).
Document Type (Tipo de Documento) Una declaracin de tipo de documento (DOCTYPE) es obligatoria en la mayora de los lenguajes de marcas hipertextuales y sin ella es imposible realizar la validacin.
La declaracin comienza el documento Web y le dice a la herramienta de validacin que versin se est utilizando para realizar el control de la gramtica del lenguaje. Esta opcin permite anular la declaracin DOCTYPE del documento. Usted puede utilizar esta opcin con fines de prueba, pero es muy probable que el documento HTML deba ser asociado con la declaracin DOCTYPE, sino la herramienta de validacin determinara que el documento no es vlido. A modo de ejemplo, un mensaje sera: No DOCTYPE Declaration Found! (Declaracin DOCTYPE no encontrado!).
List Messages Sequentially (Listar Mensajes Secuencialmente) Esta opcin permite listar los mensajes de error en orden ascendente.
Group Error Messages by Type (Agrupar Mensajes de Error por Tipo) Esta opcin permite listar los mensajes de error agrupados por tipo de error.
Show Source (Mostrar Cdigo) Presenta los mensajes de error asociados con las lneas de cdigo fuente donde se detectan.
Clean up Markup with HTML Tidy (Limpiar Marcado con HTML Tidy) Show Outline (Mostrar Esquema) Esta opcin permite generar un resumen del documento Web desde el elemento H1 a H6. La presentacin es una estructura de rbol lo cual permite una visualizacin mas fcil para ver los errores detectados.
Validate error pages (Validar pginas de error) La herramienta mostrar si la pgina a validar no puede ser recuperada (por ejemplo, si el servidor present el siguiente mensaje 404 not found (404 no encontrado).
Verbose Output (Verbose Salida) Esta opcin permite presentar la informacin de manera detallada, ya que aade ms explicaciones y sugerencias de los resultados validados.
Informe HTML
Una vez realizada la revisin, se presenta un informe o resumen HTML con informacin sobre el resultado. El mismo se encuentra dividido en las siguientes secciones:
Primera seccin
En esta seccin encontrar la cantidad de errores detectados y la cantidad de recomendaciones a seguir (Result), la direccin de la pgina validada, la codificacin de caracteres al que est asociado la pgina, la versin que est siendo utilizada para realizar el control de la gramtica del lenguaje.
Segunda seccin
Esta seccin presenta las opciones seleccionadas en una primera instancia para realizar el proceso de validacin. En caso de querer realizar un nuevo proceso de validacin con otras opciones indquelas y haga clic en el Revalidate (Revalidar).
Tercera seccin
Cuarta seccin
En esta seccin encontrar indicados cada uno de los errores encontrados. Los iconos utilizados por esta herramienta son los siguientes:
Se han encontrado problemas de accesibilidad que hay que corregir (errores). Se han encontrado problemas de accesibilidad de menor prioridad que los primeros (informativos).
La herramienta presenta: el nmero de lnea y nmero de columna donde fue detectado el problema (Line xx, Column nn). ttulo del problema detectado (resaltado en negrita). cdigo fuente donde fue detectado el problema (de manera resaltada (color rojo y subrayado)).
Quinta seccin
Aqu se presenta el cdigo fuente utilizado como entrada en el proceso de validacin.
Como colocar el logotipo en sus pginas

W3C confiere distintos logotipos que pueden ser utilizados en aquellas pginas Web que hayan pasado con xito el proceso de validacin de una tecnologa determinada.
Ejemplo
En la pgina de la herramienta http://validator.w3.org/docs/help.html#validation_basics,
seccin "valid" icons, encontrar el cdigo XHTML para a integrar el icono dentro de la pgina Web validada. A modo de ejemplo: <p> <a href="http://validator.w3.org/check/referer"><img src="http://www.w3.org/Icons/valid-xhtml10" alt="Valid XHTML 1.0!" height="31" width="88" /> </a> </p> Es recomendable que el icono se enlace con la pgina Web de la herramienta, de esta manera el logotipo queda vivo. O sea, cualquier visitante de la pgina Web validada podr hacer clic sobre el logotipo y comprobar efectivamente que se trata de un documento validado y no de un logotipo o imagen trampa a modo de cumplimiento solamente. Si el logotipo es utilizado como un vnculo para volver a validar la pgina Web el cdigo deber ser diferente.
Validador Hojas de Estilo en Cascada (CSS) de W3C

Es un servicio online de validacin de Hojas de Estilo en Cascada (CSS Cascading Style Sheets) y documentos (X)HTML (con hojas de estilo) del W3C (World Wide Web Consortium). En general, los documentos Web estn desarrollados con lenguajes de marcas hipertextuales (HTML, (X)HTML, SMIL, MathML, SVG, DTD SGML, XML, etc.). Estos lenguajes pueden utilizarse para crear pginas con informacin estructurada. Para el uso de colores, texto y posicionamiento se utiliza un lenguaje de estilo llamado CSS. Esta herramienta ayuda a comparar y corregir en caso que sea necesario, las Hojas de Estilo en Cascada (CSS) con las especificaciones tcnicas CSS. De esta manera se pueden encontrar errores comunes, tipogrficos o usos incorrectos. La herramienta tambin presenta los riesgos relacionados con la usabilidad de la CSS.

Se accede a la misma a travs de la Web oficial. http://jigsaw.w3.org/css-validator/ La versin es gratuita.
Servicio de Validacin de Hojas de Estilo en Cascada - CSS Validation Service
Una vez que se accede al sitio Web oficial se presenta la siguiente pantalla, la cual contiene tres vistas que le permiten validar por la URL de la pgina con CSS o solo el CSS, validar un archivo y validar cdigo directamente:
Vista - Validate by URL (Validar por URL)
Pasos a seguir: Escriba en el campo Address (Direccin) la direccin de la pgina Web (URL) a validar y haga clic en el botn Check (Chequear).
Puede utilizar Ms Opciones (More Options) para configurar alternativas en la herramienta.
Las opciones le permiten: Perfil (Profile) Seleccionar el perfil que desea comprobar de CSS. Por defecto, comprobar el cumplimiento de CSS versin 2.1, que es la recomendacin actual a nivel tcnico de CSS.
Las Advertencias Determinar el nivel de detalle del proceso de validacin. Puede incluir todos los tipos de mensajes o seleccionar algunos. Existen dos tipos de mensajes: o Errores (errors). Ocurren cuando el cdigo fuente no sigue las reglas CSS. o Advertencias (warnings). No son consideradas un problema respecto al cdigo fuente, si ayudan a advertir sobre futuros comportamientos extraos por parte de determinados usuarios. Medio En las hojas de estilo es importante especificar como es un documento que se presentar en distintos medios (pantalla, papeles, dispositivo Braille, etc.). Por defecto, esta opcin se encuentra determinada en todos (all) ya que es el medio adecuado para todos los dispositivos.
Los nombres para los distintos tipos de medios estn asociados a los dispositivos de destino. Algunos de ellos son: -Todos: medio adecuado para todos los dispositivos. -Braille: dispositivos de retro alimentacin tctil Braille. -Impresin: destinados para documentos a ver en pantalla en modo vista previa de impresin. -Pantalla: destinados principalmente a pantallas color. -Proyeccin: destinados a presentaciones proyectadas, como por ejemplo los proyectores. -Televisin: destinados a los dispositivos de tipo televisin (baja resolucin, color, sonido disponibles).
Nota: por ms informacin sobre medios ver http://www.w3.org/TR/CSS2/media.html.
Informe HTML
Primera seccin
En esta seccin se presentan dos links cuyos nombres representan la cantidad de errores y advertencias detectadas. Un tercer link se encuentra asociado al cdigo de la Hoja de Estilo validada (Su Hoja de Estilo validada). Los Errores
Las Advertencias
La herramienta presenta: el nmero de seccin donde fue detectado el problema, ttulo del problema detectado y la descripcin con recomendaciones a seguir.
Su Hoja de Estilo validada
Como incluir el Logotipo en sus pginas

W3C confiere distintos logotipos que pueden ser utilizados en aquellas Hojas de Estilo en Cascada (CSS) que hayan pasado con xito el proceso de validacin.
A modo de ejemplo: Si la Hoja de Estilo en Cascada (CSS) no presenta errores, los logotipos presentados podrn ser utilizados en el cdigo de la pgina Web validada, con el cdigo que la propia herramienta ofrece.
Ejemplo
Ejemplo para logotipo dorado (Gold): <p> <a href="http://jigsaw.w3.org/css-validator/check/referer"> <img style="border:0;width:88px;height:31px" src="http://jigsaw.w3.org/css-validator/images/vcss" alt="CSS Vlido!" /> </a> </p> Ejemplo para logotipo azul (Bue): <p> <a href="http://jigsaw.w3.org/css-validator/check/referer"> <img style="border:0;width:88px;height:31px" src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="CSS Vlido!" /> </a> </p>
Es recomendable que el icono se enlace con la pgina Web de la herramienta, de esta manera el logotipo queda vivo. O sea, cualquier visitante de la pgina Web validada podr hacer clic sobre el logotipo y comprobar efectivamente que se trata de un documento validado y no de un logotipo o imagen trampa a modo de cumplimiento solamente. Si el logotipo es utilizado como un vnculo para volver a validar la pgina Web el cdigo deber ser diferente.
Validacin de la Accesibilidad
TAW (Test de Accesibilidad Web)
TAW es una familia de herramientas, desarrollada por la Fundacin CTIC (Centro Tecnolgico de la Informacin y de la Comunicacin), que permite el anlisis automtico del nivel de accesibilidad alcanzado en el diseo y desarrollo de los sitios Web. El nivel se mide de acuerdo con las Pautas de Accesibilidad al Contenido Web (WCAG 1.0 y 2.0) del WAI-W3C. La utilizacin de las herramientas est destinada al pblico en general, profesionales como Webmasters, diseadores y desarrolladores de sitios Web.

La versin online de la herramienta TAW analiza las Pautas de Accesibilidad al Contenido Web 2.0 (WCAG 2.0). En esta versin el nivel de adecuacin es doble A (AA) y las tecnologas analizadas son HTML y CSS. Se accede a la misma seleccionando la opcin Herramientas del sitio Web oficial http://www.tawdis.net/
y luego seleccione en el men de navegacin la opcin Accesibilidad La versin disponible es gratuita.
TAW3 Online (WCAG 2.0)

Pasos a seguir: 17. Ingrese en la herramienta: http://www.tawdis.net/tools/accesibilidad/
Seleccione la normativa de accesibilidad WCAG 2.0 (ver Vista WCAG 2.0 beta). Luego introduzca la direccin URL de la pgina o sitio Web y haga clic en el botn analizar.
Una vez realizada la revisin, se presenta un informe HTML con informacin sobre el resultado:
En el informe encontrar la siguiente informacin del anlisis: Sitio Web analizado Fecha y hora de realizado el anlisis Pautas utilizadas Nivel de adecuacin para facilitar la referencia con otras organizaciones. El nivel de adecuacin doble A (AA) indica que el sitio Web es accesible.
La versin TAW3 Online WCAG 2.0 analiza las tecnologas HTML y CSS.
En el resumen de los resultados le indicar: Problemas - total de problemas encontrados. Advertencias - total de advertencias. No verificados - total de puntos no verificados.
Los resultados son presentados de acuerdo a las tres categoras descriptas, por cantidad total y organizados por cada principio (Perceptible, Operable, Comprensible y Robusto).
Puede seleccionar en la parte superior del informe las diferentes vistas: Vista Marcada, Detalle y Listado. El Informe detallado lo encuentra a partir del link situado en la parte inferior y est asociado a la Vista Detalle. A partir de este link se accede a ms informacin respecto a las incidencias. Dicho link se encuentra asociado con la Vista Detalle. Los iconos utilizados por esta herramienta son los siguientes:
No se han encontrado problemas de accesibilidad.
Problemas de accesibilidad detectados automticamente es necesario realizar correcciones. Advertencias se requiere una revisin manual de los posibles problemas de accesibilidad. Imposible realizar comprobacin automtica la comprobacin debe ser completamente manual. na: No aplicable.
Tipos de problemas de accesibilidad

Una vez generado el informe HTML el primer paso es focalizarse en la cantidad de problemas detectados por la herramienta. Los mismos son sealados por la herramienta por si sola y es necesario seleccionar las actividades pertinentes para corregirlos y solucionarlos. El segundo paso se centra en la cantidad de advertencias detectadas por la herramienta. Las advertencias indican la existencia de posibles problemas, los cuales debern revisarse manualmente y analizar si los mismos deben ser confirmados o descartados.
El tercer paso se centra en la cantidad de puntos no verificados detectados por la herramienta. La herramienta indica que los mismos no pueden validarse o comprobarse automticamente, entonces para ello ser necesario realizar una validacin manual completa del sitio Web.
Nota: Es necesario recordar que para que el resultado final sea exitoso siempre se deben validar los posibles problemas de accesibilidad manuales del sitio Web. Las herramientas automticas no realizan una evaluacin completa. Por ende, al no asegurar que el nivel de accesibilidad es de un 100%, es necesario realizar pruebas adicionales utilizando herramientas de evaluacin manual.
Resolucin de problemas de accesibilidad

A la hora de realizar las actividades de correccin se recomienda acceder a la informacin proporcionada por la Vista Detalle. En la misma se presentan los problemas detectados mostrando las lneas de cdigo afectadas y que tcnicas son aconsejables para su resolucin.
Vista Detalle En esta vista Detalle aparecer: La informacin de anlisis. El detalle por cada principio de las pautas, una descripcin del principio, las pautas en las que se encontraron incidencias y la descripcin de la incidencia. Para cada incidencia se presentan las tcnicas aconsejadas para solucionar el problema. Resultado incidencias: cantidad de incidencias por tipo de problema de accesibilidad (ver iconos). Nmero de lneas: lneas de cdigo donde se detectan incidencias. Los problemas se presentan de acuerdo a la estructura del documento HTML analizado (sitio Web) diferenciando por sus elementos (HTML (Global, Cdigo fuente) y CSS (Cdigo fuente)).
Ejemplo
Ejemplo de Detalle por Principio
Nombre: Principio 1 Perceptibilidad. ---Descripcin: la informacin y los componentes de la interfaz de usuario deben presentarse a los usuarios de la manera en que puedan percibirlos. ---Topologa: Pauta 1.1 Alternativas textuales
1.1.1 Contenido no textual Presenta incidencias --- Comprobacin: Pauta 1.1 Alternativas textuales 1.1.1 Contenido no textual Presenta incidencias Imgenes sin atributo alt --- Tcnicas: la tcnica suficiente y aconsejable es H37 - Using alt attributes on img elements. --- Resultado incidencias: total de incidencias 11 de tipo Problema. --- Nmero de lneas: 114, 147, 159, 172, 181, 193, 196, 203, 232, 247, 249.
Como utilizar el Logotipo

TAW confiere distintos logotipos que indican el nivel de accesibilidad alcanzado del sitio Web en relacin a las Pautas de Accesibilidad para Contenido Web WCAG 1.0.
Ejemplo
A modo de ejemplo:
(X)HTML <span class="tawlogo"> <acronym title="Test de accesibilidad Web versin 3"> t<span style="color: rgb(255, 0, 0);">.</span> a<span style="color: rgb(220, 131, 16);">.</span> w<span style="color: rgb(0, 170, 0);">.</span><sup>3</sup> </acronym> <span class="tnivel"><abbr title="Nivel A - WCAG 1.0 WAI">A</abbr></span></span>
Es recomendable que el icono se enlace con la pgina Web de la herramienta, de esta manera el logotipo queda vivo. O sea, cualquier visitante de la pgina Web validada podr hacer clic sobre el logotipo y comprobar efectivamente que
se trata de un documento validado y no de un logotipo o imagen trampa a modo de cumplimiento solamente. Si el logotipo es utilizado como un vnculo para volver a validar la pgina Web el cdigo deber ser diferente.
Link Checker de W3C

Es un servicio online de chequeo de links y anclas en las pginas o sitos Web del W3C (World Wide Web Consortium). La herramienta lee un documento HTML o XHTML extrayendo la lista de enlaces y comprueba que no existen enlaces rotos, que no estn definidos dos veces, que todos son referenciables y advierte sobre las redirecciones HTTP (incluyendo el directorio redireccines).

Se accede a la misma a travs de la Web oficial. http://validator.w3.org/checklink La versin actualmente disponible: v4.5. y es gratuita.
Link Checker
Una vez que se accede al sitio Web oficial se presenta la siguiente pantalla:
Pasos a seguir: Escriba la direccin de la pgina Web (URL) a validar y haga clic en el botn Check (Chequear). Puede utilizar Ms Opciones (More Options) para configurar alternativas en la herramienta: 1. Summary only (Solamente presentar sumario) 2. Hide redirects (Ocultar redirecciones). All (Todas) For directories only (Solamente para directorios)
A modo de ejemplo, esta opcin presenta los enlaces que no estn rotos pero donde el documento no utiliza la direccin exacta (URL), proponiendo la direccin de vinculacin final en aras de ganar velocidad en las bsquedas. Dont send the Accept-Language header (No envo de la cabecera Accept-Language) Dont send the Referer header (No envo del encabezado Referer)
Check linked documents recursively, recursion depth: (Verifica documentos vinculados de forma recursiva, donde se determina la profundidad de la recursividad) Save options in a cookie (Las opciones seleccionadas se guardan en una cookie)
Informe HTML
Primera seccin
En esta seccin se presentan los siguientes links: ---Processing, la pgina procesada (Processing + URL) ---Go to the results, los resultados obtenidos del anlisis realizado ---For reliable link checking results, check HTML validity first. See also CSS validity La herramienta presenta el resultado de realizar la validacin de cdigo del documento Web (HTML validity) y la validacin de las Hojas de Estilo en Cascada (CSS validity). Por ms informacin ver las herramientas: Validador (X)HTML de W3C y/o Validador Hojas de Estilo en Cascada (CSS) de W3C, descriptas en esta misma gua. ---Back to the link checker, regreso a la herramienta Link Checker.
Segunda seccin
La herramienta presenta el estado del documento procesado, la cantidad total de segundos que llev realizar el anlisis de todo el sitio y la cantidad total de segundos que llev realizar el anlisis de cada vnculo del sitio.
Tercera seccin
En esta seccin se presentan los resultados del anlisis, con el listado de los links (URL) en los cuales se detectaron problemas junto con el detalle de las acciones sugeridas a realizar (List of broken links and other issues) y el listado de los hiperlinks duplicados o vacos (Anchors).
W3C mobileOK Checker

Es un servicio online del W3C (World Wide Web Consortium) de verificacin de documentos Web, que comprueba el nivel de adecuacin de la pgina tiene para ser utilizado en dispositivos mviles.

Se accede a la misma a travs de la Web oficial http://validator.w3.org/mobile/ La versin actualmente disponible: v1.2.1. y es gratuita.
W3C mobileOK Checker

Pasos a seguir: Escriba la direccin de la pgina Web (URL) a validar y haga clic en el botn Check (Chequear). Puede presentar los datos por categora o de acuerdo al testeo realizado, para eso seleccione una de las opciones que aparecen en la pantalla.
Informe HTML
---Result (Resultado), la puntuacin entre 0 y 100 se calcula en funcin de la cantidad y el nivel de severidad de las fallas encontradas por el verificador.
Cada falla est asociada a un nivel de severidad, que puede ser: critico (critical), este tipo de falla impide la prestacin del servicio en la mayora de los dispositivos mviles. grave (severe), este tipo de falla no impide la prestacin del servicio, pero inciden fuertemente en la experiencia del usuario. medio (medium), este tipo de falla se presenta cuando algunas limitaciones de los mviles no estn siendo debidamente tenidos en cuenta. bajo (low), se presenta cuando es posible realizar mejoras tiles.
Cada nivel de severidad cuesta un nmero determinado de puntos, por ejemplo la falla asociada a un nivel de severidad medio tiene un costo de 5 puntos. El resultado se calcula: 100 menos la suma de los costos de las fallas encontradas.
---Page Size (Tamao de la Pgina), representa el nmero total de bytes que se recuperan de un navegador mvil para presentar la pgina. Incluye el tamao de: la pgina, de las imgenes incrustadas, la hoja de estilo (CSS) y tambin incluye el tamao de los posibles cambios de direccin intermedia que puede ser necesaria para recuperar la pgina.
---Network - Number of Requests (Nmero de Solicitudes), representa el nmero de bsquedas HTTP que un navegador mvil tiene que realizar para presentar la pgina. Cada bsqueda tiene asociado un costo, debido a la alta latencia tpica de las redes mviles.
---Where to start (Por donde comenzar), si la herramienta de verificacin devuelve una cantidad o un nivel de severidad alto de las fallas esta seccin presenta una tabla de resultados los cuales es necesario hacer foco para as mejorar el manejo de la pgina a nivel mvil.
AChecker (Web Accessibility Checker)

Es una herramienta desarrollada por ATRC (Adaptive Technology Resource Centre), que permite evaluar el contenido de una pgina Web conforme a diversos estndares de accesibilidad, entre ellos se encuentran las Pautas de Accesibilidad al Contenido Web (WCAG 1.0 y 2.0) del WAI-W3C.

Se accede a la misma a travs de la Web oficial http://www.achecker.ca/checker/index.php La versin online de la herramienta (Achecker v 1.0) analiza las Pautas de Accesibilidad al Contenido Web 2.0 (WCAG 2.0). En esta versin el nivel de adecuacin es "A", "doble A" (AA) y "triple A" (AAA). La versin online disponible es gratuita.
Web Accessibility Checker

Haga clic en el Link de Registro, de esta manera crear una cuenta de usuario en el sistema.
Luego complete el formulario de registro, el cual cuenta con los siguientes campos o atributos:
* Indicates required fields (*): el asterisco indica cuales campos son obligatorios a la hora de completar el formulario. Login Name: nombre con el cual se va a realizar el login en el sistema. Se recomienda que contenga solo letras, nmeros, underscores (subraya), guiones o perodos. El mximo de caracteres es veinte (20). Password: contrasea. Se recomienda utilizar una combinacin de letras, nmeros y smbolos. El mnimo de caracteres es ocho (8) y el mximo de caracteres es quince (15). New Password Again: ingresar la contrasea anterior nuevamente.
Email Address: direccin de e.mail. First Name: primer nombre. Last Name: apellido.
Una vez creada la cuenta y realizado el login en el sistema, se presenta la siguiente pantalla, la cual contiene las siguientes vistas:
---Guidelines Esta vista presenta las directrices que gestiona este sistema en particular. ---Profile En esta vista se gestionan los datos relacionados con la persona que efectu el login (nombre, apellido, cambio de password, cambio de direccin de e.mail, etc.).
Luego seleccione el estndar o la normativa de accesibilidad contra la cual evaluar. Para ello, haga en la vieta Options que desplegar las siguientes opciones:
-Enable HTML Validator (Activar HTML Validator). Cuando esta opcin esta activada la herramienta enva el contenido al W3C Servicio de Validacin de Marcado (http://validator.w3.org/) el cual identifica errores de marcado (ver Validador (X)HTML de W3C). -Show Source (Mostrar fuente). La herramienta presenta el cdigo HTML de la pgina evaluada y vincula los problemas de accesibilidad detectados a las lneas del cdigo fuente donde se producen. -Guidelines to Check Against (Directrices contra las cuales verificar). Aqu se activan o desactivan las casillas para seleccionar las normativas de accesibilidad
contra las cuales evaluar. Por defecto, la casilla WCAG 2.0 (Level AA) ya se encuentra seleccionada. Luego introduzca la direccin URL de la pgina Web (Check Accessibility by URL) y haga en el botn Check It (Analizar).
La herramienta tambin permite evaluar el contenido HTML de la pgina Web subiendo el archivo HTML a evaluar (Check Accessibility by File Upload). Una vez realizada la revisin, se presenta un informe con todos los problemas de accesibilidad detectados:
Tipos de problemas de accesibilidad

La herramienta identifica tres tipos de problemas de accesibilidad
Los problemas conocidos son aquellos identificados con certeza como barreras de accesibilidad. Los mismos son sealados por la herramienta por si sola y es necesario seleccionar las actividades pertinentes para corregirlos y solucionarlos. Los problemas posibles son aquellos identificados como advertencias que indican la existencia de probables obstculos. Los problemas no identificados son aquellos detectados que la herramienta no puede identificar. La herramienta indica que los mismos no pueden comprobarse automticamente, entonces para ello ser necesario realizar una validacin manual completa del sitio
Web y confirmar que el problema identificado no est presente.
Logotipo
Actualmente, AChecker confiere logotipos que indican el nivel de accesibilidad alcanzado del sitio Web en relacin a las Pautas de Accesibilidad para Contenido Web WCAG 1.0. Es recomendable que el icono se enlace con la pgina Web de la herramienta, de esta manera el logotipo queda vivo. O sea, cualquier visitante de la pgina Web validada podr hacer clic sobre el logotipo y comprobar efectivamente que se trata de un documento validado y no de un logotipo o imagen trampa a modo de cumplimiento solamente. Si el logotipo es utilizado como un vnculo para volver a validar la pgina Web el cdigo deber ser diferente.
Recomendaciones tcnicas para desarrolladores

Al momento de implementar el portal los equipos de desarrollo se encuentran con el desafo de seguir tcnicas y estndares que permitan cumplir con las pautas de accesibilidad WCAG 2.0. A continuacin se han desarrollado recomendaciones y ejemplos que los desarrolladores puedan tomar como base para comenzar.
1. Perceptibilidad
El criterio de Perceptibilidad (en ingls perceivable content) indica que la informacin debe ser presentada a los usuarios de la forma en que stos pueden percibirla.
1.1. Alternativas textuales:

Proporcione alternativas textuales para todo contenido no textual, de manera que pueda modificarse para ajustarse a las necesidades de las personas, como por ejemplo en una letra mayor, braille, voz, smbolos o un lenguaje ms simple.
Contenido no textual (A)

Deber proveerse una alternativa de texto equivalente y accesible para los contenidos no textuales que se presenten. En el caso particular de las imgenes, se debe especificar en todos los casos una descripcin corta en el atributo alt, del tag <img>. Para proveer una descripcin completa, es posible especificar un enlace a una pgina que la contenga, en el atributo longdesc del tag <img> que corresponde a la imagen. Esta tcnica asegura el cumplimiento de la pauta, pero se recomienda para una solucin ptima presentar a un lado de la imagen un texto corto que la describa, y un enlace a la descripcin completa. La ventaja de esta tcnica es que se podr utilizarla tambin para otros contenidos no textuales, de manera que la forma de acceso a los textos alternativos sea homognea.
Algunos contenidos no textuales no tienen una alternativa equivalente en texto como los controles, los elementos de entrada de datos, contenido multimedia dependiente del tiempo, captcha y elementos de decoracin.
Controles y elementos de entrada de datos

El caso de los Controles y elementos entrada de datos deben tener un nombre que los describa.
Ejemplo
Asociar un tag <label> a cada campo de entrada de datos del formulario (tags <input> de tipo text, checkbox, radio, file o password), igualando el atributo for del tag label al id del tag input La etiqueta de un campo de entrada de texto, donde el atributo for coincide con el id del campo.
<label for="idApellido">Apellido:</label> <input type="text" name="apellido" id="idApellido" />
Ejemplo
Ejemplo de una lista de seleccin con checkboxs :

<h1>Exportacin de reporte</h1> <p>Especifique un formato y luego presione el boton exportar.</p> <form action="http://example.com/exportacion" method="post"> <p> <input type="radio" name="formato" id="xml" value="XML" /> <label for="xml">Formato XML</label><br/> <input type="radio" name="formato" id="pdf" value="PDF"/> <label for="pdf">Formato PDF</label><br/> <input type="radio" name="formato" id="doc" value="DOC"/> <label for="honey">Formato MS .DOC</label><br/>
<input type="submit" value="Exportar reporte"/> </p> </form>
Otra alternativa es completar el atributo title de estos tags, esto es suficiente para describir estos campos correctamente. Con estas tcnicas se asegura la interpretacin por parte de las tecnologas de asistencia ms utilizadas.
Contenido multimedia dependiente del tiempo (videos, audios)

Cuando el usuario no pueda disponer de una alternativa a un contenido de naturaleza no textual, es necesario brindarle una descripcin que le permita identificar este contenido y su propsito. Para este objetivo, una tcnica razonable consiste en colocar una descripcin corta de texto en una posicin adyacente al elemento no textual. En casos que lo ameriten, se podr incluir en esta descripcin corta un enlace a una descripcin completa del elemento, por ejemplo para un video se podr mostrar el ttulo del video en la descripcin corta, e incluso si fuera posible su guin en una descripcin completa.
CAPTCHA13:
Si el contenido no textual est orientado a determinar que el usuario es efectivamente un ser humano se debe proveer un medio alternativo de validacin que requiera otras capacidades sensoriales. Por ejemplo, un CAPTCHA que consista en reconocer un texto en una imagen debe estar descripto como tal en un texto adyacente y adems debe proveer un enlace a otro mecanismo alternativo que no requiera utilizar el sentido de la vista, por ejemplo un contenido auditivo o la resolucin de una operacin aritmtica expresada en lenguaje natural.
13
Un captcha (en ingls Completely Automated Public Turing test to tell Computers and Humans Apart) es un mecanismo que permite determinar si quien accede a una aplicacin o un sitio Web es un humano o una mquina.
Decoracin o formato
Las imgenes que se utilicen nicamente para decoracin deben tener atributo alt= , para indicar que la tecnologa asistiva no debe anunciar su existencia. Una mejor alternativa es el uso de imgenes declaradas slo en las hojas de estilo CSS, mediante propiedades como background, background-image, que permiten especificar imgenes para los elementos del HTML, independientes del contenido.
Ejemplo
Veamos un ejemplo correcto de un sitio con las imgenes y sin las imgenes. Se seleccion la pgina principal Blogger, www.blogger.com:
En la versin sin imgenes, toda la informacin est presentada en forma de texto, y solo las imgenes decorativas carecen de descripcin alternativa.
Observe cmo funciona el texto alternativo en el logo de Blogger, que sin importar que no est la imagen igualmente se transmite la informacin. Y adems observe como el resto de la pgina se sigue entendiendo a pesar de que no estn las imgenes cargadas.
Ejemplo
Veamos otro ejemplo de un sitio con las imgenes y sin las imgenes. El ejemplo seleccionado es la pgina principal de Ebay (http://www.ebay.com). En el caso de Ebay, se puede apreciar en la versin de texto que aquellas imgenes que conforman la estructura de la pgina no tienen alternativas comprensibles, por ejemplo los ttulos de las categoras no tienen texto alternativo. La imagen con el logo del sitio (ebay) tiene como texto alternativo From collectibles to cars, buy and sell all kinds of items on eBay. De esta manera, el usuario que accede a la pgina por un medio alternativo no percibir la misma informacin que se muestra en la pgina con las imgenes. Este es uno de los casos que se busca evitar con este criterio.
Observe la pgina con las imgenes:
Observe la pgina sin las imgenes:
Contenido multimedia dependiente del tiempo

Solo audio y solo video (pregrabado) (A)
En los casos en los que el audio o video no es el contenido principal, sino que constituye un contenido alternativo para una versin de texto, como en el caso de animaciones que ilustran un contenido textual, alcanza con identificarlos como tales por una descripcin textual adyacente, como se explica en el punto 1.1.1. En caso contrario, para contenido de solo audio es necesario proveer una transcripcin textual del contenido. En cuanto al contenido de solo video, alcanza tanto con una alternativa textual completa del video como con un contenido de audio que relate lo que sucede en el video.
Subttulos (pregrabados) (A)

En los casos en los que el audio o video no es el contenido principal, sino que constituye un contenido alternativo para una versin de texto, como en el caso de videos ilustrativos para un contenido textual, es suficiente la tcnica descripta en 1.1.1 de identificar el texto con una descripcin textual. Todos los videos que constituyen en s mismos un contenido principal y por lo tanto que no sean alternativos a un contenido textual deben contener subttulos. Es importante tomar en cuenta que estos subttulos no slo deben mostrar lo que se dice en el video, sino tambin describir los sonidos que se oyen, y que podran brindar informacin (aplausos, golpes, sonidos de maquinaria).
Publicacin de videos con subttulos

Para el cumplimiento de este punto, es deseable asociar los subttulos al contenido audiovisual. Varios formatos de video (.AVI, .MKV) permiten incorporar diferentes pistas de subttulos a los videos. En todos los casos, deber comprobarse que el medio que se utilice para su publicacin provea acceso a estos subttulos. En el caso particular de la publicacin de videos a travs de Adobe Flash, es necesario elegir una alternativa que asegure la accesibilidad de los videos. Una posibilidad es el uso de JW FLV Media Player de la empresa LongTail, que permite asociar subttulos (closed captions) y una pista secundaria de audiodescripcin al video que se publica. Esta solucin es de uso libre para fines no comerciales. Algunas instrucciones en ingls para su uso pueden encontrarse en http://www.longtailvideo.com/support/tutorials/Making-VideoAccessible .
En el caso de usar herramientas que no tienen una versin en espaol, como la que se describe, debern proveerse los subttulos activados desde el comienzo, o una explicacin textual de cmo activarlos.
Generacin de videos con subttulos

Para generar videos con subttulos existen diferentes tcnicas. La mayora de los programas profesionales de manejo de videos proveen alguna funcionalidad para este fin. Para los videos a publicar mediante Adobe Flash, se puede utilizar Subtitle Horse, disponible en http://subtitle-horse.org/ (en ingls). Esta herramienta permite generar archivos de subttulos a partir de videos publicados en internet. Estos subttulos debern ser asociados a los videos en su publicacin para asegurar la accesibilidad. Otra forma de asegurar que los subttulos siempre estn disponibles para el usuario es integrarlos directamente a la imagen del video (hardsubs en ingls). Esto es posible a travs de programas de edicin de video, y adems existen programas dedicados especficamente a esta tarea. Una alternativa disponible de forma libre es Avidemux, disponible en http://fixounet.free.fr/avidemux/ (en ingls), a travs del plugin Subtitler.
Audiodescripcin o alternativa multimedia (A)

En los casos en los que el audio o video no es el contenido principal, sino que constituye un contenido alternativo para una versin de texto, como en el caso de videos ilustrativos para un contenido textual, como se indica en los casos anteriores es suficiente la tcnica descripta en 1.1.1 de identificar el texto con una descripcin textual. Todos los videos que constituyen en s mismos un contenido principal y por lo tanto que no sean alternativos a un contenido textual, deben proveer una pista de audio alternativa que describa lo que sucede en el video. Para esto pueden usarse varias tcnicas que requerirn distintos niveles de esfuerzo. La alternativa ms simple consiste en grabar la pista de audiodescripcin mientras se lee el video, y asociar el archivo de audio al video desplegado, como pista complementaria de audiodescripcin. Si estos videos se publican en Adobe Flash, las herramientas recomendadas en 1.2.2 permiten la publicacin de estos archivos de audiodescripcin. Otra posibilidad consisten en ofrecer como alternativa otro video que reemplace completamente el audio original por otro que contenga la audiodescripcin, o incluso una alternativa que agregue pausas que permitan una audiodescripcin detallada cuando sea necesario.
Otra alternativa para el cumplimiento es proveer un enlace a una descripcin textual completa de todo lo que sucede en el video.
Subttulos (directo) (AA)

Se proporcionan subttulos para todo contenido de audio en directo del contenido multimedia sincronizado. Esta tcnica refiere a la transmisin de contenidos multimedia con audio en directo. Para asegurar el cumplimiento es necesario contar con equipamiento especial que permita por ejemplo el subtitulado de los videos que se transmitan en directo a travs de pginas Web. La tecnologa de reconocimiento de voz disponible comercialmente no permite an generar estos subttulos de forma automtica en la mayora de los casos. Por esta razn, esta tarea deber realizarse manualmente en el momento de la generacin del contenido. El World Wide Web Consortium recomienda una herramienta para este fin en el siguiente enlace (en ingls): http://www.w3.org/TR/2008/NOTE-WCAG20TECHS-20081211/G9
Audiodescripcin (pregrabada) (AA)

Se proporciona una audiodescripcin para todo contenido de vdeo pregrabado del contenido multimedia sincronizado. Para el cumplimiento de esta pauta se puede hacer uso de las tcnicas en 1.2.3, sin la posibilidad de brindar una alternativa textual. En este caso, todos los videos que se muestran deben contar con audiodescripcin.
Adaptabilidad
El propsito de este principio es asegurar que toda la informacin del sitio se encuentra disponible en un formato que pueda ser percibido por cualquier usuario, como por ejemplo: hablado o presentado en una forma visualmente ms sencilla. Si estos formatos pueden ser determinados por el software, entonces podrn ser presentados a los usuarios en diferentes formas (visual, audible, tctil) segn sus necesidades. Si por el contrario la informacin est embebida en la presentacin de tal forma que el programa no pueda determinar la tcnica
necesaria para asistir al usuario, entonces el software no podr desplegar otros formatos distintos que los usuarios requieran.
Informacin y relaciones (A)

Los documentos pueden utilizar medios visuales para transmitir informacin, estructura o relaciones dentro de su contenido. Es necesario comprobar que esta informacin no se pierde al utilizar diferentes medios para acceder al documento, por ejemplo a travs de un lector de pantalla. Por ello debe comprobarse que los destaques, las relaciones entre diferentes partes del texto y la relacin jerrquica entre los encabezados se pueden determinar sin necesidad de interpretar visualmente el documento.
Documentos de texto no estructurado

Para la presentacin de textos en formato de texto plano u otras tecnologas que no proveen mecanismos para describir la semntica del texto, es necesario indicar la estructura del texto de alguna forma fcil de interpretar para el usuario. Dejar espacios entre prrafos y hacer uso de sangras a fin de estructurar la informacin. Destacar los ttulos con espaciados especiales, por ejemplo doble espaciado para los ttulos ms importantes. Utilizar asteriscos para resaltar texto destacado, adems de negritas.
Documentos en HTML
El lenguaje HTML permite expresar la estructura y las relaciones del texto explcitamente en el documento. Si se cumple con esto, es posible aplicar los formatos visuales de forma homognea. La mayora de los usuarios percibirn esta informacin de forma visual, pero los usuarios que lo necesiten podrn percibirla a travs de tecnologas asistivas. Por ejemplo, un lector de pantalla podr pronunciar un texto con nfasis, si est correctamente indicado en el cdigo HTML. Tambin ser ms fcil la navegacin entre bloques de texto, si stos tienen los ttulos correspondientes. Utilizar los tags <h1>, <h2> y <h3> para definir encabezados de texto y <p> para los diferentes prrafos.
Ejemplo
Aqu se presenta un ejemplo sencillo de uso de tags para definir la estructura del texto:
<h1>Principios de Gobierno Electrnico en Red</h1> <h2>Principio de igualdad</h2> <p>El uso de medios electrnicos no implicar la existencia de restricciones o discriminaciones para las personas que se relacionen con la Administracin Pblica por otros medios, tanto en la prestacin de servicios pblicos, como en cualquier actuacin o procedimiento administrativo, sin perjuicio de las medidas dirigidas a incentivar el uso de las tecnologas.</p> <h2>Principio de accesibilidad</h2> <p>La Administracin Pblica deber garantizar la accesibilidad a la informacin y a los servicios por medios electrnicos de manera segura y comprensible, con especial nfasis en el cuidado del acceso universal y su adecuacin a mltiples soportes, canales y entornos, con el objetivo de que todas las personas puedan ejercer sus derechos en igualdad de condiciones.</p>
Para garantizar accesibilidad no es suficiente destacar visualmente un texto que se desea resaltar, es necesario adems marcarlo con tags semnticos. Esto permite que un lector de pantalla distinga como hacer la inflexin de la voz durante la lectura y por ejemplo permitir aumentar el nivel de destaque del texto segn las necesidades de personas con visin disminuida.
Inflexiones en el texto
Se recomienda usar <strong> para texto resaltado, en lugar de negritas (<b>) y marcar el nfasis con <em> en lugar de itlicas (<i>).
Citas
Contamos con el elemento <q> para demarcar citas cortas, <blockquote> para citar bloques de texto y <cite> para referenciar a las fuentes.
Siglas, abreviaturas y definiciones

Los elementos <abbr> y <acronym> se utilizan para mostrar abreviaturas y acrnimos, mostrando el texto al que corresponden en el atributo title. El
elemento <dfn> se utiliza para demarcar la definicin de un trmino que se utilizar en el documento.
Ejemplo
Aqu se presenta un ejemplo sencillo del uso de tags para inflexiones, citas en el texto y abreviaciones:
<h1>nfasis y resaltado: elementos em y strong</h1> <p>...Lo que <em>realmente</em> quise decir fue: "No me parece bien, me parece <strong>excelente</strong>!"...</p> <h1>Citas y referencias: elementos blockquote, q y cite</h1> <p> <q>El poder de la Web est en su universalidad. El acceso por cualquier persona, independientemente de la discapacidad que presente es un aspecto esencial</q> </p> <p>Tim Berners-Lee, Director del <abbr lang="en" title="World Wide Web Consortium">W3C</abbr> e inventor de la World Wide Web. </p> <p>Hablar de Accesibilidad Web es hablar de un acceso universal a la Web, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localizacin geogrfica y capacidades de los usuarios. </p> <p> Fuente: <cite>Gua Breve de Accesibilidad Web</cite>, <abbr lang="en" title="World Wide Web Consortium">W3C</abbr>. </p> <h1>Siglas, abreviaturas y definiciones: elementos abbr, acronym y dfn </h1> <p><dfn>Gobierno Electrnico</dfn> es el uso de las tecnologas de la informacin y de la comunicacin (<abbr title="Tecnologas de la informacin y de la comunicacin">TIC</abbr>) en los rganos de la Administracin Pblica para mejorar la informacin y los servicios ofrecidos a los ciudadanos, orientar la eficacia y eficiencia de la gestin pblica e incrementar sustantivamente la transparencia del sector pblico y la participacin de los ciudadanos. <p>
Ref: <cite>Carta Iberoamericana de Gobierno Electrnico</cite>, junio 2007. </p>
Estos son los tags HTML que tienen mejor soporte en el software de accesibilidad disponible , pero no son los nicos tags semnticos disponibles que se pueden utilizar. Existen adems otros tags para distintos usos de destaque (DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM tal como se especifica en http://www.w3.org/TR/html4/struct/text.html#h-9.2.1 (en ingls). Junto con estas tcnicas, es conveniente utilizar estilos CSS para manejar la presentacin del contenido, que permitan separar la distribucin lgica del contenido de su presentacin. Ver Anexo Estructura de HTML y CSS, C22, o el original en ingls en el sitio de World Wide Web Consortium: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C22).
Secuencia significativa (A)

Con el fin de que las diferentes tecnologas representen correctamente la jerarqua del texto, es importante mantener una relacin entre la disposicin del HTML y la del texto que se despliega. Para esto es deber asegurarse que el contenido HTML tenga el mismo orden que lo que se despliega en pantalla, y evitar tcnicas que alteren visualmente el orden de los elementos en pantalla. Una herramienta razonable para comprobar el cumplimiento es ver el despliegue de la pgina en un navegador de texto, y comprobar que el orden de los elementos que se despliegan sigue la misma lgica que el despliegue visual diseado originalmente. Una herramienta til para simular el punto de vista de un lector de pantalla es la extensin Fangs para el navegador Firefox disponible en http://www.standards-schmandards.com/projects/fangs/ (en ingls). Fangs permite desplegar el texto que escuchara el usuario de un lector de pantalla. Tambin muestra una representacin de la estructura de la pgina, y su jerarqua de encabezados. Mediante su uso es posible validar que la pgina mantenga su sentido al momento de utilizar otro medio.
Caractersticas sensoriales (A)

Todos los usuarios deben poder utilizar el contenido, inclusive cuando no pueden percibir el tamao o la forma de los objetos de la pantalla, o cuando no pueden utilizar la informacin sobre ubicacin espacial u orientacin (por ejemplo: botn redondo, ubicado a la derecha, etc.).Para ello, cuando se plantea una referencia a un elemento de la pantalla, es necesario que esa referencia no sea nicamente visual. Alcanza para el cumplimiento de este criterio evitar las instrucciones que slo refieran por ejemplo al color o forma de un elemento en pantalla. En el caso de un texto que refiere al botn de abajo a la derecha, debe ser reemplazado por botn con la etiqueta Siguiente de abajo a la derecha.
Distinguible
Este principio busca garantizar que todos los usuarios puedan ver y escuchar el contenido que incluye una pgina, separando claramente el contenido propiamente dicho (en ingls foreground) de los elementos que forman parte del contexto o fondo (en ingls background)
Empleo del color (A)

Asegurarse de que el color no es el nico elemento que distingue al contenido. En los casos en que las diferencias de color tengan un significado especial, es necesario proveer otras pautas visuales que provean la misma informacin, de modo que quienes no ven los colores igual puedan percibir la informacin.
Control del audio (A)

Si se reproduce automticamente cualquier audio por ms de 3 segundos, debe haber un control para parar el audio, o un control de volumen exclusivo para la pgina o el sitio, en el comienzo de la misma.
Contraste (mnimo) (AA)

La presentacin visual de textos debe tener un contraste significativo con el fondo. El cumplimiento est asegurado en los casos en los que se evita especificar los colores del texto y fondos, ya que el navegador utiliza en estos casos la configuracin por omisin que es en general de alto contraste. A la hora de elegir y utilizar paletas de colores para las pginas que contienen texto, es necesario tener en cuenta el cumplimiento de este punto. Se puede comprobar el cumplimiento de la relacin de contraste mediante herramientas como las especificadas en el apartado Resources de la siguiente pgina de W3C: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS20081211/G18#G18-resources Si por algn motivo se desea mantener textos de bajo contraste con el fondo, existe la alternativa de no cumplir con el punto en la versin principal y brindar un enlace alternativo, con el mismo contenido textual, y cumpliendo los requerimientos de contraste mnimo. Por supuesto, el enlace mediante el cual se accede a esta alternativa s tiene que cumplir con el requerimiento de contraste mnimo.
Variar el tamao del texto (AA)

Se permite algn medio para especificar el tamao del texto. En el pasado se desaconsejaba el uso de px como medida para el texto, porque algunos navegadores no permitan aumentar el tamao del texto en ese caso. Si bien es una buena prctica slo utilizar tamaos relativos, em o de texto, alcanza con comprobar que el tamao del texto aumenta correctamente.
Asimismo, tambin es necesario probar que el aumento del tamao del texto hasta el 200% no deforma la presentacin visual hasta el punto de hacerla difcil de leer.
Imgenes de texto (AA)

El cumplimiento se asegura fcilmente evitando las imgenes de texto, y es lo que se recomienda. Slo son aceptables las imgenes de texto en los casos en que la presentacin es esencial, como ejemplo en el logo de producto. En estos casos se admiten imgenes de texto, adems de una descripcin textual alternativa con las tcnicas descriptas en 1.1.1 . Tambin es posible usar imgenes de texto si adems se provee una forma de permitir al usuario cambiar su tamao en la representacin visual, y otras funcionalidades esperables para el contenido textual. De todas maneras, no se recomienda su uso.
Operabilidad
La interfaz de usuario, sus componentes y su navegacin deben ser operables. Esto significa que los usuarios deben poder interactuar con la interfaz para poder lograr sus objetivos.
Accesible a travs de teclado

Toda la funcionalidad debera ser accesible utilizando slo el teclado
Teclado (A)
Toda la funcionalidad debera ser accesible utilizando slo el teclado sin necesidad de tiempo especfico para presionar cada tecla. No existe un conjunto de tcnicas particulares para asegurar el cumplimiento de este criterio ya que el comportamiento por omisin de los navegadores se encarga de asegurarlo. Los problemas surgen en el momento de agregar riqueza a la interaccin, en los que se modifica el funcionamiento normal del navegador. Es en estos casos en los que se debe tener especial cuidado de no limitar el uso desde el teclado. Por ejemplo: a la hora de implementar funcionalidades del estilo de arrastrar y colocar elementos de la pgina, se deber proveer una funcionalidad equivalente por teclado, tal como el mecanismo de cortar y pegar para los mismos elementos y comprobar que sea operable por teclado.
Como regla general es necesario comprobar que cualquier interaccin con la pgina que se realice con el mouse y que exceda el seguimiento de un enlace, sea pasible de ser realizada a travs del teclado o que exista la posibilidad de una interaccin alternativa que lo admita. Un punto relevante es que slo se admite que las formas de entrada de teclado dependan del tiempo cuando esto sea imprescindible para la interaccin esperada. Un ejemplo esta dado por la situacin en la que el control de un video a travs de teclado dependa del tiempo para elegir dnde pausar este video. Una prueba acadmica con lmites de tiempo tambin podra limitar el tiempo para el ingreso de sus respuestas, si esto fuera imprescindible. Contrariamente, no es aceptable por ejemplo un campo de entrada de password que provea un tiempo lmite para el ingreso de los datos, aunque esto fuera visto como una caracterstica de seguridad. En el caso particular de los formularios, es necesario asegurarse de que el diseo toma en cuenta al usuario de teclado, sobre todo a la hora de agregar funcionalidad al comportamiento normal del navegador. Por ejemplo, en formularios, si se utiliza javascript para alterar el manejo estndar de los evento keypress, keydown o keyup, es necesario comprobar que esta alteracin no choca con la funcionalidad estndar de la navegacin de teclado. Tambin debe asegurarse a travs de pruebas que en ningn caso sea necesario utilizar el mouse para llegar a un control, o para hacer alguna accin. Esto es, que la tecla Enter permita hacer el envo de un formulario que se est editando, y que la tecla de tabulacin permita recorrer todos los campos. A la hora de implementar cada funcionalidad adicional o alternativa a la navegacin as como el manejo de formularios es importante asegurar el cumplimiento de este principio. Alcanza con comprobar que la nueva funcionalidad puede tambin lograrse evitando usar el mouse.
Sin vas muertas de teclado (A)

Si un usuario puede llegar a un componente de la pgina con el teclado, debe poder salir de l y continuar utilizando la interfaz tambin con el teclado. El no cumplimiento de este criterio slo se consigue modificando explcitamente el comportamiento del navegador, por ejemplo a travs de plugins. Si se incluye un plugin en la pgina, como un video incrustado en un tag <object/>, un java applet, o un contenido flash, es necesario comprobar que
estos elementos respetan las expectativas del usuario en cuanto a navegacin de la pgina. En general, es necesario comprobar que el usuario que pone el foco del teclado en un video, a travs de la tecla Tab, tambin puede mover el foco a otro elemento de la pgina, con la misma tcnica. Con esto se asegura que el usuario no necesite utilizar un mouse para salir del contenido. Si es necesario utilizar alguna combinacin de teclas particular para salir de un contenido, alcanza con especificarlo en un texto adyacente al contenido (Por ejemplo: Para salir del video, presione la tecla Esc). Por ltimo, si el plugin utilizado no permite cambiar el foco a otro elemento de la pgina utilizando solamente el teclado, las alternativas son dos. En caso de ser posible, se implementar esta funcionalidad si el plugin provee algn lenguaje de scripting. En caso contrario, no se podr incluir este plugin en la pgina. Eventualmente se puede proveer este contenido a travs de un enlace, con una advertencia que anuncie que se pasa a contenido no accesible.
Tiempo suficiente
La interfaz debe proveer a los usuarios de suficiente tiempo para leer y utilizar el contenido.
Lmite de tiempo ajustable (A)

Los lmites de tiempo pueden estar relacionados con funcionalidad o scripts en la misma pgina, o responder a limitaciones de las sesiones del servidor, atendiendo a criterios de seguridad o desempeo. En el primer caso, las tcnicas son mltiples, comenzando con evitar los scripts que desplazan el texto a leer, o por supuesto, comprobar a travs de pruebas el cumplimiento de este criterio. Este desplazamiento puede lograrse por mltiples tcnicas, y cada una de ellas tiene sus propias formas de asegurar el cumplimiento. En cuanto a limitaciones en el tiempo de lectura de la pgina, alcanza con comprobar que estas limitaciones sean esenciales y en caso contrario eliminarlas. Acerca de las sesiones de servidor, la estrategia es diferente. Las sesiones de servidor se utilizan en aplicaciones Web que almacenan informacin variada del usuario, por ejemplo sus credenciales de seguridad, y otros datos que el usuario ingresa. Las sesiones tienen un tiempo mximo de vida porque en primer lugar consumen recursos del servidor y en segundo lugar su duracin demasiado extendida podra generar problemas de seguridad. Se busca evitar que estos tiempos mximos generen problemas al usuario con dificultades de accesibilidad. Debido a que las sesiones se implementan en el lado del servidor, las tcnicas concretas a utilizar difieren de acuerdo a las tecnologas utilizadas y a la configuracin de cada aplicacin. Como regla general, ser necesario proveer algn mecanismo para asegurar que las sesiones se mantienen abiertas por un tiempo configurable o por todo el tiempo en el que se est usando la pgina. Para esto, diferentes tecnologas proveen formas de manipular el tiempo de expiracin de las sesiones:
Ejemplo
Manipulacin del tiempo de expiracin de la sesin, para que se mantenga vlida por 20 horas: public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.getSession().setMaxInactiveInterval(20 * 3600); }
Ejemplo
Ejemplo Visual Basic .NET: Manipulacin del tiempo de expiracin de la sesin, para que se mantenga vlida por 20 horas: Session.Timeout = 20 * 60;
Otra forma de implementar un mecanismo similar es proveer algn componente javascript para realizar peridicamente pedidos de tipo AJAX al servidor, y as actualizar el contador de tiempo de la sesin (mecanismo de keepalive). Esto permite que el tiempo mximo de la sesin del servidor nunca se alcance, mientras el usuario trabaja con la pgina, asegurando cumplimiento de esta pauta. Esto podra generar problemas de seguridad con usuarios que dejaran sus ventanas abiertas despus de haber terminado de trabajar con la aplicacin. Por esto, el mecanismo de keepalive puede ser opcional, y estar disponible para ser activado en todas las pginas de la aplicacin, de acuerdo a la necesidad del usuario.
Un ltimo caso en el que pueden generarse problemas con los lmites de tiempo arbitrario es en el de las pginas de redireccin con lmite de tiempo. El siguiente cdigo es interpretado por el navegador como una orden de redirigir a otra pgina en 5 segundos.
<meta http-equiv="refresh" content="5; url=http://www.example.com/pagina2.html" />
Esto no cumple con el criterio 2.2.1. Para cumplir alcanza con poner el tiempo de espera en 0:
<meta http-equiv="refresh" content="0; url=http://www.example.com/pagina2.html" />
De todas maneras, este mtodo de redireccin no es recomendado. El estndar HTTP permite hacer una redireccin a partir de la respuesta del servidor con el cdigo 301 (la pgina se movi en forma permanente) y 302 (la pgina se movi en forma temporal). En el caso de las aplicaciones Web, los lenguajes de programacin ofrecen mltiples formas de enviar estas redirecciones.
Ejemplo
Redireccin a travs de una pgina JSP de Java public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.sendRedirect("/pagina2.jsp"); }
Ejemplo
Ejemplo Visual Basic .NET: Redireccin a travs de Visual Basic .NET en una pgina ASP.NET: Response.Redirect("/pagina2.aspx")
Ejemplo
Ejemplo PHP: Redireccin a travs de una pgina PHP

<?php
header("HTTP/1.1 301 Moved Permanently); header("Location: http://www.example.com/pagina2.php"); ?>
Pausar, detener y ocultar (A)

Esta pauta apunta al contenido habitualmente conocido como animado o en movimiento. Incluye especialmente las imgenes en movimiento y pelculas, presentaciones, animaciones, juegos en tiempo real y marquesinas, entre otros. Si este tipo de contenidos comienzan automticamente, duran ms de 5 segundos y son presentados junto con otros contenidos, se debe proveer al usuario de un mecanismo para detener, pausar o esconderlo, salvo que la animacin sea realmente parte esencial del contenido. Un caso especial de animaciones lo constituyen los contenidos que se actualizan automticamente sin accin adicional del usuario, como la informacin del tiempo, cotizaciones de la moneda y pginas de noticias que se recargan completamente en forma peridica. Tambin para este contenido si comienza a actualizarse sin accin alguna del usuario y es presentado junto con otro contenido, debe proveerse un mecanismo para detener, pausar o esconderlo, salvo que la animacin sea parte esencial del contenido o la interaccin.
No provocar ataques
Los individuos que tienen problemas de fotosensibilidad pueden ser afectados por contenido que parpadea a ciertas frecuencias si el parpadeo se mantiene ms de unos pocos ciclos.
Tres destellos o por debajo del umbral (A)

La forma ms fcil de asegurar el cumplimiento es simplemente evitar los contenidos que destellan. De todas maneras, hay contenidos animados que por su naturaleza contienen destellos o parpadeos. Para asegurar el cumplimiento, alcanza con comprobar que ningn componente de la pgina destella ms de tres veces en el perodo de un segundo. La nica tcnica recomendada consiste en comprobar el cumplimiento, cada vez que se agregan o actualizan contenidos que contienen animaciones. An si se utilizan contenidos que parpadeen ms de tres veces, alcanza con medir el tamao de este contenido y comprobar que su rea es menor que la de un rectngulo de 340 x 250 pixeles. Una tcnica simple para comprobarlo es obtener una captura de pantalla y hacer la medida del contenido sobre el resultado. Si se comprueba que el tamao de todos los elementos que parpadean es inferior al mximo propuesto, se cumple con este criterio.
Navegable
El objetivo de este principio es ayudar a los usuarios a encontrar el contenido que necesitan, a la vez que mantiene control de su ubicacin en el sitio. Estas tareas son habitualmente ms difciles para los usuarios con discapacidades. Los objetivos perseguidos se pueden atender, si conseguimos que la estructura interna del documento publicado sea coherente con la estructura visual que se presenta en el despliegue en un navegador estndar. Debido a que esta estrategia es coherente con la utilizada en el punto 1.3.1 (Informacin y relaciones), las tcnicas presentadas en ese punto tambin ayudan en este apartado.
Saltar bloques (A)

Se debe permitir a los usuarios que navegan por varias pginas acceder directamente al contenido primario o central de cada pgina, salteando los bloques que se repiten, como por ejemplo los menes de enlaces, los cabezales y los espacios de publicidad. Si se sigue el lineamiento de mantener la coherencia entre la estructura del documento y la estructura visual, ser fcil para el navegador interpretar el
formato de los bloques del documento y para el usuario seleccionar las partes que desea leer. Se pueden brindar apoyos adicionales a la estructura ordenada del documento. Es deseable proveer un componente de navegacin al principio del documento que enlace a las diferentes partes que lo componen. Adicionalmente, al principio de cada seccin, un enlace al final de la misma o al siguiente bloque. Estas tcnicas sern diversas de acuerdo a las tecnologas utilizadas. Por ejemplo, algunos manejadores de contenido proveen estos componentes de navegacin. Si se cuenta con templates para la generacin de contenidos, se puede hacer uso de los encabezados y pies de bloques para asegurar esta navegabilidad.
Pgina titulada (A)

Comprobar que las pginas que se publican, o que se generan, contienen el elemento <title>
Ejemplo
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Pagina Principal</title> </head> <body> ... </body> </html>
Orden de foco (A)

Si se sigue el criterio de mantener la coherencia entre la estructura del documento y la estructura visual, los navegadores se encargan de mantener el cumplimiento de este criterio. En caso de no hacerlo, slo se puede asegurar el cumplimiento comprobando mediante pruebas que el orden del foco del teclado sigue la secuencia esperable, de acuerdo a la distribucin de los elementos de la pgina.
A la hora de introducir o mantener algn mecanismo explcito de manejo del foco, por ejemplo a travs de javascript, tambin ser necesario hacer pruebas de navegador para asegurarse del cumplimiento de este criterio.
Propsito de un vnculo (en su contexto) (A)

Es necesario que el propsito de un vnculo se pueda inferir a partir de su texto, o al menos del texto que lo rodea no slo visualmente, sino tambin en el fuente HTML del documento. La forma ms simple de asegurar el cumplimiento de este criterio es seguir las pautas para mantener la correspondencia entre la estructura del documento y su despliegue. Para comprobar que se cumple este criterio es necesario desplegar el sitio en algn navegador no estndar, como un navegador de texto, y verificar que es posible comprender a dnde apuntan los enlaces, prescindiendo de parte de la informacin visual.
Mltiples medios (AA)

Las pginas deben ser accesibles de mltiples formas y no solamente desde vnculos internos y particulares del sitio, con la excepcin de aquellas pginas que son un resultado o un paso en un proceso. Ejemplos de forma de acceder a una pgina son los favoritos, buscadores y menes contextuales. Para cumplir con esta pauta es imprescindible que toda pgina tenga una URL, algo que a pesar de resultar simple no est tan extendido como debera, producto de los sitios construidos con Flash u otras tcnicas de programacin. Una forma de asegurar el cumplimiento de esta pauta es proveer listas de vnculos relacionados, tablas de contenido, mapas totales o parciales del sitio y pginas que renen exhaustivamente todos los vnculos del sitio.
Encabezados y etiquetas (AA)

Utilizar los elementos de encabezado (<h1> al <h6>) en una jerarqua ordenada y consistente, para titular los bloques de texto con texto que describa el contenido. Esto puede ser utilizado por las tecnologas de asistencia, para ayudar al usuario a encontrar los contenidos que busca sin tener que leerlos completamente.
En los casos en los que los encabezados no son aplicables, se puede etiquetar cualquier elemento HTML que tenga id=idElemento con un tag <label for=idElemento> , de forma anloga al primer ejemplo del apartado 1.1.1 . Incluso, si no se desea mostrar esta etiqueta en el despliegue usual, puede ocultarse esta etiqueta mediante hojas de estilo, asignando una clase invisible para el elemento label.
Foco visible (AA)

La interfaz por teclado debe proveer una forma de operacin en la que el indicador del foco del teclado est siempre visible. En los casos en los que se decide manipular explcitamente el despliegue del indicador de foco, es necesario asegurarse de que esta accin no genera la prdida del cumplimiento de este criterio. En tecnologas alternativas, testear que se mantiene cumplimiento o eliminar la tecnologa alternativa. Si no se modifica explcitamente el despliegue del foco, el navegador o agente de usuario utilizar los indicadores estndar del sistema operativo con este fin. En el caso de los sistemas Microsoft Windows, por ejemplo, el foco de texto se representa con una barra vertical intermitente, y el foco de un enlace, con un fino recuadro punteado que lo envuelve. Debido a que el indicador de foco usual puede ser insuficiente para algunos usuarios, el sistema operativo provee controles para mejorar el destaque de estos indicadores, por ejemplo aumentando su tamao y contraste. Debe tenerse cuidado a la hora de modificar este comportamiento, an si el objetivo es mejorar la accesibilidad, ya que cualquier forma no estndar de representar el foco, puede escapar a esta posibilidad de modificacin por parte del usuario. Por esto, cualquier mejora que se intente hacer a la representacin del foco, deber complementar y no reemplazar a los indicadores estndar. En este caso no es necesario utilizar ninguna tcnica particular, sino slo asegurarse de que los elementos de la pantalla que reciben el foco, lo representan de forma estndar. Un test exhaustivo podra realizarse configurando el sistema operativo para utilizar texto con alto contraste, y comprobar que esta configuracin se respeta, moviendo el foco por todo el contenido a desplegar. Adicionalmente, otro aspecto a tomar en cuenta es el contenido manejado por algn plugin, por ejemplo flash, o applets java. Estas tecnologas tienen la posibilidad de alterar los indicadores de foco del teclado y del mouse, y su comportamiento. Es necesario comprobar que no se degrada la accesibilidad
mediante su uso, como por ejemplo la posibilidad de utilizar contraste alto para los cursores.
Comprensible
Este principio tiene como finalidad permitir que todo el contenido textual pueda ser ledos por los usuarios y las tecnologas que los asisten, as como garantizar que la informacin necesaria para comprenderlos est a su alcance.
Legible
El idioma (espaol, ingls, etc.) de cada pgina debe estar determinado por el fuente HTML de la pgina.
Idioma de la pgina (A)

El tag HTML de comienzo de la pgina tiene que contener los atributos lang="es" xml:lang="es" para los contenidos en espaol y anlogamente para otros idiomas en los que se publiquen contenidos.
Ejemplo
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es"> <head> ... </head> <body> ... </body> </html>
Predecible
Las pginas deben operar de modo previsible, es decir, de la forma que sugiere su apariencia.
En foco (A)
Cuando un componente recibe el foco, no debe iniciar ningn cambio al contexto. Para ello, es necesario evitar el uso de eventos de foco para disparar comportamientos de la pgina. El problema ms comn se da en el uso del evento onFocus de javaScript. Se recomienda evitar manipular el foco del teclado en este evento, por ejemplo:
Ejemplo
Uso errneo del evento onBlur

<input type="submit" onFocus="this.blur();">
La mayora de los usos del evento onFocus pueden generar confusiones en el usuario, si generan algn cambio de contexto. Tambin es recomendable evitar los formularios que se envan automticamente al recibir el foco en algn elemento. Este es un comportamiento que se encuentra en algunos formularios de mltiples pginas, intentando ahorrar clics, pero debe evitarse. Otro comportamiento desaconsejable es el uso de ventanas emergentes al cargar una pgina, o al poner el foco en un elemento de la pantalla. En caso de ser necesario utilizar ventanas emergentes, se recomienda activarlas con algn tipo de accin, como un clic a un botn o a un enlace. La tcnica ms importante en este caso es ejecutar un test, recorriendo con la tecla de tabulacin todos los elementos de la pgina y comprobando que no se disparan acciones automticas que pudiesen confundir al usuario.
Durante la entrada de datos (A)

Algunas acciones de entrada de datos, como seleccionar un elemento de una lista, o una opcin de un radio, en algunos casos provocan cambios de contexto.
Estos cambios deben ser evitados siempre que no se haya avisado al usuario de que se trata del comportamiento normal. En los casos en los que estos cambios de contexto no sean esperables por el usuario, se proveer una descripcin textual previa y adyacente en la estructura del documento, para que el usuario comprenda el resultado que tendr la accin. En el caso de los envos de formularios, si bien esto genera un cambio de contexto, alcanza con utilizar slo botones de tipo submit para ejecutar esa accin, ya que es el comportamiento esperable. Si hay otra accin que enviar el formulario, ser necesario explicarlo en un texto adyacente al elemento que la activar. Por ejemplo, si la seleccin de una lista enviar el formulario, el documento tendr un texto antes de esta lista, que anuncie el envo del formulario. Si hay enlaces o botones que lancen ventanas emergentes a travs de javaScript, tambin ser necesario anunciar este comportamiento. No ser imprescindible en el caso de usar el atributo target para abrir un enlace en otra ventana, ya que es el mecanismo estndar y ser correctamente interpretado por el navegador.
Ejemplo
Enlace que abre en una ventana nueva

<a href="pagina1.html" target="_blank">Abrir pgina 1 (en una ventana nueva)</a>
Navegacin consistente (AA)

Los mecanismos de navegacin deben comportarse siempre de la misma forma a lo largo de mltiples pginas Web dentro de un sitio. La tcnica ms til para este punto es utilizar los mecanismos del software disponible (templates, includes, generacin de contenidos) para generar los elementos de navegacin de la misma manera en todas las pginas del sitio. Se busca evitar la generacin manual de pginas de navegacin, que podran no ser consistentes en su estructura.
Identificacin consistente (AA)

Los componentes de las pginas que tienen la misma funcionalidad, deben ser identificados de la misma forma. Para ello es recomendable hacer uso de clases CSS para identificar los diferentes componentes de las pginas. Es deseable utilizar clases CSS con nombres descriptivos, a fin de que las tecnologas asistivas consigan identificar la funcin de los bloques del documento.
Ayuda a la entrada de datos

En este apartado identificamos varias tcnicas para asistir en el uso de formularios Web.
Identificacin de errores (A)

Cuando se detecta un error, se debe informar al usuario en texto qu tem ocasion el error y cul fue el error ocasionado. En el caso de campos obligatorios, es recomendable que se incluyan descripciones de texto que indiquen cules son estos campos. Tambin es recomendable prevenir el envo del formulario sin estos campos utilizando tcnicas de scripting en el cliente, como javaScript. La situacin es similar cuando se trata de restricciones a los datos que pueden ser ingresados en un campo. Se recomienda en este caso proveer una descripcin textual cuando el usuario incluye informacin que no est en la lista de valores permitidos, cuando el valor ingresado no tiene el formato adecuado o est fuera del rango permitido. En este caso tambin es una tcnica vlida prevenir los errores con scripting del lado del cliente, a lo que se suma utilizar elementos de destaque y agregar los textos de error utilizando la DOM (Document Object Model - estndar que constituye la base del despliegue del documento dentro del navegador)
Instrucciones o etiquetas (A)

Cuando se requiere que el usuario ingrese contenido en un formulario Web, los campos para este fin deben estar debidamente etiquetados con etiquetas e instrucciones precisas, evitando sobrecargar la pgina con informacin innecesaria.
Se busca asegurar que la informacin que se le provee al usuario sea suficiente para comprender el cometido y el efecto de su entrada de informacin. El cdigo HTML debe seguir las recomendaciones establecidas en el apartado Controles, entrada de datos de la pauta 1.1.1. Opcionalmente se pueden utilizar los elementos fieldset y legend para agrupar controles de entrada de datos.
Sugerencia tras error (AA)

Si se detecta un error y se conocen los mecanismos para corregirlo, se debe sugerir al usuario la forma de hacerlo, con la nica excepcin de los casos en que estas explicaciones comprometen la seguridad. Se recomienda mostrar los errores en una lista, en un lugar adyacente al error. Opcionalmente, colocar el foco en el primer elemento a corregir, si esto no genera un cambio de contexto inesperado, por ejemplo slo hacerlo luego de un submit, y no en la correccin automtica en lnea.
Prevencin de errores (legales, financieros, de datos) (AA)

Para transacciones que tienen consecuencias legales o financieras: En el caso general, es deseable que las transacciones realizadas por el usuario sean reversibles. Esto ayuda a paliar la gravedad de las consecuencias de eventuales errores de interaccin. Depende de la naturaleza de cada aplicacin la forma como se provee esta funcionalidad. El principio a seguir es disear el modelo de datos de la aplicacin de forma que prevea un borrado lgico de los datos y su eventual recuperacin. De todas maneras, para las operaciones que por su naturaleza son irreversibles, es necesario contar con alguna salvaguarda para evitar errores. En un formulario que ejecute una accin con consecuencias potencialmente irreversibles, deben tomarse en cuenta varios puntos: Una advertencia previa al control que realiza la accin, que explique sus consecuencias en lenguaje claro y simple. Si fuera necesario, proveer adems un enlace a una explicacin ms detallada.
Requerir del usuario una accin que exprese su comprensin de esta advertencia. Es posible proveer un checkbox inicialmente deshabilitado, para que el usuario exprese que ha ledo la advertencia correspondiente. La habilitacin de este checkbox ser requisito para ejecutar la accin. Esto tambin puede asegurarse con un botn de aceptacin de la advertencia, siempre que este no sea el botn predeterminado del formulario. En las transacciones que lo permitan, especialmente aquellas que se componen de varios pasos, proveer una instancia de revisin. Agregar un paso extra a la transaccin que consista en la revisin de los datos que la componen, para permitir al usuario, una vez completados sus datos, ocuparse de verificar su correccin, y de comprender las consecuencias de la accin. Esto ayuda a usuarios con eventuales dificultades de lectura, o tambin cognitivas, a evitar errores.
Robustez
El contenido debe ser diseado de una forma robusta, de tal modo que pueda ser interpretado en forma confiable por una amplia variedad de programas de usuario, incluyendo aquellos que implementan tecnologas de asistencia a la discapacidad.
Compatible
Este principio tiene como fin maximizar la compatibilidad de las pginas con los programas de usuario actuales y futuros, incluyendo las tecnologas de asistencia.
Interpretacin (A)
Con el fin de asegurar que las diferentes tecnologas de navegacin consigan interpretar correctamente las pginas que se publican, es necesario asegurar que los documentos HTML o XML publicados tengan un formato correcto. En el caso de la publicacin de pginas estticas, alcanza con cerrar los tags de HTML, y validar las pginas que se publican. Para sitios manejados con sistemas de manejo de contenidos, ser necesario contar con herramientas que ayuden para el cumplimiento, adems de templates que generen HTML o XHTML correctos.
El servicio de validacin de w3c disponible en http://validator.w3.org/ puede ser utilizado para probar la correccin de pginas publicadas que estn publicadas en internet (opcin Validate by URI), o pginas guardadas en un archivo html (opcin Validate by File Upload) Otras herramientas que pueden servir de ayuda a la hora de validar los contenidos Web publicados puede encontrarse (en ingls) en Techniques for WCAG 2.0, G134: Validating Web pages: http://www.w3.org/TR/2008/NOTEWCAG20-TECHS-20081211/G134#G134-resources.
Nombre, rol, valor (A)

En el caso de los formularios estndar de HTML, alcanza con etiquetar correctamente los campos a llenar. Las tcnicas descriptas bajo Controles, entrada de datos en el punto 1.1 son suficientes para asegurar la correcta identificacin de los controles de los formularios. En el caso de las tecnologas alternativas, como Flash o controles ActiveX, es deseable identificar con texto cada uno de los elementos de interaccin de la pgina. Esto es de importancia sobre todo cuando se incorporan nuevas formas de interaccin, que podran depender por ejemplo de una interpretacin visual para su uso y el descubrimiento de su funcin podra ser imposible para los usuarios que accedieran a travs de tecnologas asistivas. Por esto se aconseja comprobar que la funcionalidad introducida con estas tecnologas sea accesible, mediante pruebas especficas o bien proveer alternativamente esta funcionalidad a travs de tecnologas accesibles. En el caso de que la funcionalidad no accesible sea meramente decorativa, alcanza con una descripcin textual del contenido no accesible, para su correcta interpretacin por parte del usuario.
Anexo estructura del HTML y CSS

C22: Usar CSS para controlar la presentacin visual del texto
(Extracto de Techniques for WCAG 2.0: C22 (en ingls): http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C22)
El objetivo de esta tcnica es ejemplificar el uso de CSS (hojas de estilo en cascada) para controlar la presentacin visual del texto. Esto permite al usuario modificar las caractersticas del texto de acuerdo a su user agent para cumplir con sus requerimientos. Estas caractersticas incluyen el tamao, color, familia de tipografas, y el posicionamiento relativo. CSS beneficia la accesibilidad primordialmente separando la estructura del documento de su presentacin. Las hojas de estilo han sido diseadas con el fin de permitir un control preciso del espaciado entre caracteres, alineacin del texto, posicin de los objetos en la pgina, salida de audio y de voz, y otras caractersticas, por fuera del cdigo HTML del documento. Al separar el estilo del cdigo los autores tienen la posibilidad de mantener ms claro y simple el cdigo que define los contenidos, hacindolo a su vez ms accesible. El texto contenido en imgenes acarrea varios problemas de accesibilidad, incluyendo la imposibilidad de: ampliar el texto de acuerdo a lo configurado en el navegador cambiar el color del texto a lo establecido en el navegador o en hojas de estilo del usuario respetar configuraciones del sistema operativo, por ejemplo alto contraste
Es preferible utilizar texto verdadero para la porcin textual de estos elementos, y una combinacin de cdigo semntico y hojas de estilo para generar la presentacin visual correspondiente. Para que esto funcione efectivamente, es recomendable elegir tipografas comunes y otras tipografas de reemplazo para el caso en que los usuarios tengan la primera. Como beneficio adicional, los navegadores actuales tienen capacidad de utilizar sub-pixel rendering para generar texto ms elegante y legible en pantallas LCD que lo que es posible con imgenes de texto.
Las siguientes propiedades CSS son tiles para dar estilo al texto, evitando la necesidad de utilizar texto en imgenes. font-family para elegir la tipografa. text-align para alinear el texto a la derecha, izquierda o centro. font-size para modificar el tamao del texto. font-style para mostrar itlicas. font-weight para modificar el grosor del texto. color para elegir el color del texto o de los bloques que lo contienen. line-height para elegir el grosor de las lneas. text-transform para cambiar capitalizacin del texto. letter-spacing para establecer espaciado entre letras. background-image para mostrar un fondo de imagen detrs de un texto. first-line se puede utilizar para modificar la presentacin de la primera lnea de un bloque de texto, por ejemplo para mostrar sangras francesas. first-letter permite modificar el despliegue de la primera letra de un bloque de texto. before y after se pueden utilizar para mostrar contenido decorativo antes y despus de un bloque de texto.
Anexo otras tecnologas

Las recomendaciones que preceden son aplicables a los documentos que se publican, sin importar la tecnologa que se utilice. De todas maneras, estn ms bien orientadas a las caractersticas de los contenidos HTML. En los casos en los que se decida utilizar otras tecnologas, es necesario asegurarse de que el contenido publicado sea accesible o que se provea alternativa accesible.
Contenidos Flash
En el caso de los contenidos publicados en Adobe Flash la tcnica ms simple es proveer una alternativa textual. Si se construyera un sitio basndose extensamente en esta tecnologa, el siguiente enlace en ingls provee tcnicas para generar Adobe Flash accesible. Seminarios Web de Paciello Group asociado a Adobe, para asegurar WCAG 2.0 en Flash (en idioma ingls): http://www.paciellogroup.com/blog/?p=185
Contenidos pdf
En el caso de los archivos PDF, deben seguirse lineamientos similares a los necesarios para asegurar cumplimiento en HTML. En el siguiente enlace se pueden encontrar algunas recomendaciones para generar documentos PDF accesibles, desde la produccin del documento original, si se parte de un documento de Microsoft Word, hasta la generacin y adaptacin del PDF, con Adobe PDF Maker, y Adobe Acrobat. PDF accesibles: metodologa (Olga Carreras, Blog Usable y Accesible): http://olgacarreras.blogspot.com/2006/09/pdf-accesibles-2metodologia.html Seminario Web de Paciello Group asociado a Adobe , para asegurar WCAG 2.0 en PDF (en idioma ingls): http://www.paciellogroup.com/blog/?p=180
Contenidos de documentos de texto

Con respecto a la creacin de documentos .doc de Microsoft Word, o tambin Open Document Format, es conveniente seguir algunos lineamientos para
ayudar a la accesibilidad. Esto se cumple tanto si el formato de publicacin es un PDF generado a partir del documento original, como si se publica en el formato original, .doc o .odt, por ejemplo. En estos casos se recomienda respetar los criterios establecidos para asegurar la accesibilidad de imgenes, textos y enlaces. En el primer caso, es necesario proveer un texto alternativo que describa o reemplace y no slo titule a las imgenes que se proveen. Los lineamientos para el texto son equivalentes a las tcnicas a utilizar en HTML. Es conveniente asignar formatos al texto solamente a travs de estilos, respetar jerarquas cuando sea relevante (Encabezado 1, Encabezado2, etc.), evitando dar estructura al documento mediante el uso de la barra espaciadora o saltos de lnea manuales. Es preferible utilizar para esto sangras, o espaciados verticales relacionados con los estilos, relacionados con la importancia de los ttulos. Esto ayuda a que las tecnologas asistivas interpreten fcilmente la estructura del texto, para representar correctamente al usuario la importancia relativa de los ttulos y permitirle la navegacin por el contenido. En los siguientes enlaces se puede encontrar un tratamiento detallado de tcnicas a utilizar en Microsoft Word 2003, y Microsoft Word 2007 para generar documentos accesibles: Cmo hacer un Word Accesible (Lourdes Moreno Lpez, Centro Espaol de Subtitulado y Audiodescripcin): http://www.cesya.es/recursos/files/WordAccesible.pdf Consejos para crear un documento Microsoft Word 2007 accesible (Lourdes Moreno Lpez, Juan Manuel Carrero y Juan Ramn Martnez , Centro Espaol de Subtitulado y Audiodescripcin): http://www.cesya.es/files/documentos/CrearDocumentoMicrosoftWord 2007Accesible.pdf
Ejemplo 1 de Poltica de Accesibilidad para incluir en el Portal

Poltica de Accesibilidad
El portal del <Nombre del organismo> est comprometido con la accesibilidad en la Web. Para lograr este objetivo, hemos seguido con las Pautas de Accesibilidad o Principios Generales de Diseo Accesible establecidas por el W3C, concretamente por el Grupo de Trabajo WAI. El <Nombre del organismo> defiende la idea de crear un portal para todos, luchando por llegar a cada ciudadano, sin que su discapacidad se convierta en un elemento discriminatorio.
Web Accesible
Para comprobar el grado de accesibilidad de la Web, hemos empleado distintas herramientas online. El resultado de este estudio es el siguiente: HERA: sin errores automticos para nivel de accesibilidad AAA. T.A.W.: sin errores automticos para nivel de accesibilidad AAA. Adems de este estudio automtico, se han realizado otro tipo de pruebas para verificar los puntos de accesibilidad en este sitio Web.
Teclas de Acceso Rpido
Este tipo de teclas se utilizan para poder navegar por el portal del <nombre del organismo> de forma accesible. Se han programado un grupo de teclas de acceso rpido que recogen las secciones del men principal (men de pestaas). Las teclas de acceso rpido son las siguientes: 1: Pgina de Inicio 2: Institucional 3: Eventos 4: . 6: Enlaces 8: Contactar
s: Ir o saltar al contenido
Uso de las Teclas de Acceso Rpido
Dependiendo del navegador que se utilice, la combinacin de teclas ser la siguiente: Tecla de Acceso Rpido + Enter en IE 4.0 Alt + Maysculas + Tecla de Acceso Rpido en Mozilla y Netscape Alt + Tecla de Acceso Rpido + Enter en IE 5 y posteriores Maysculas + Esc para activar las Teclas de Acceso Rpido en Opera Control + Tecla de Acceso Rpido en sistemas Mac OS
Ejemplo 2 Uso de los smbolos y sellos de cumplimiento

Poltica de Accesibilidad
El nuevo desarrollo de www.bde.es/Webbde/ tiene como pretensin alcanzar un nivel de accesibilidad AA ("doble A") segn las Pautas de Accesibilidad al Contenido en la Web 1.0 establecidas por el W3C . El Consorcio World Wide Web (W3C) es una asociacin internacional formada por diferentes organizaciones, personal y el pblico en general, que trabajan conjuntamente para desarrollar estndares con el fin de favorecer y difundir las buenas prcticas en desarrollo Web. Este sitio Web pretende ser accesible para todos en igualdad de condiciones, no obstante, si se encuentra con alguna dificultad o desea hacer algn comentario o sugerencia, no dude en contactar con nosotros a travs del email webmaster@bde.es.
Captulo IV
Normativa
Captulo IV Normativa | 229
Aspectos normativos
Cuando planifica la arquitectura de la informacin y los contenidos a incluir en un portal, debe tener en cuenta que hay una serie de normas que deber cumplir. Leyes N 9.739 de 17 de diciembre de 1937 y N 17.616 de 10 de enero de 2003 sobre Derechos de Autor. Estas normas permiten proteger adecuadamente las obras fruto del intelecto humano, tales como creaciones artsticas, cientficas, literarias y programas de computacin, las creaciones multimedios (creacin original de imagen y sonido en formato digital, al cual se puede acceder mediante un programa informtico) y las bases de datos electrnicas. Ley N 18.331 de 11 de agosto de 2008 de Proteccin de Datos Personales y Accin de Habeas Data, que garantiza una adecuada proteccin de los datos personales y establece una serie de principios que reglan el uso y tratamiento de stos, tanto en el mbito privado como pblico. Ley N 18.381 de 17 de octubre de 2008 sobre Acceso a la Informacin Pblica, que garantiza el Derecho de Acceso a la Informacin Pblica a todas las personas sin excepcin alguna y adems tiene por objeto promover la transparencia de la funcin administrativa. Decreto 450/09 de 28 de setiembre de 2009 sobre los Principios y lineamientos estratgicos de Gobierno Electrnico.
El objetivo de esta gua es brindar recomendaciones y modelos de clusulas que les permitan a los equipos responsables del proyecto cumplir con toda la normativa vigente.
230 | Captulo VI Normativa
Proteccin de la propiedad intelectual

Qu es la propiedad intelectual?
El trmino Propiedad Intelectual14 se reserva a los tipos de propiedad que son el resultado de creaciones de la mente humana. La Propiedad Intelectual abarca los siguientes ejes (que identifican el objeto y fin de la proteccin): a) Derechos de autor, b) Derechos Conexos (los que emanan de los Derechos de Autor), c) Patentes de Invencin, d) Proteccin a Dibujos, Modelos de Utilidad y Diseos Industriales, e) Proteccin de Marcas (signos que distinguen a las empresas, sus productos, bienes o servicios), f) Competencia Desleal. A partir de esto se reconocen una serie de derechos referidos a: 1. El derecho de autor, garantiza la proteccin de las obras fruto del intelecto humano, como creaciones artsticas, cientficas, literarias y programas de computacin, las creaciones multimedios (creacin original de imagen y sonido en formato digital, al cual se puede acceder mediante un programa informtico) y las bases de datos electrnicas. Los titulares de estos derechos de autor tienen: derechos exclusivos, o sea que tienen derecho a usar y a autorizar su uso, derechos patrimoniales, que permiten obtener remuneracin derivada de su uso, y adems derechos morales, que refieren sobre todo a que se asocie esa creacin a su persona (paternidad de la creacin).
14
Los conceptos bsicos pertenecen al Curso Introductorio de la OMPI sobre Propiedad Intelectual y del Curso sobre Gestin de la Propiedad Intelectual en Internet.
2. Tambin existen los derechos conexos al derecho de autor, que abarcan los derechos de los artistas intrpretes o ejecutantes sobre sus interpretaciones o ejecuciones, los de los productores de fonogramas y los de los organismos de radiodifusin respecto de sus programas de radio y televisin. 3. La propiedad industrial, que comprende la proteccin de signos distintivos como las marcas de fbrica o de comercio y las indicaciones geogrficas. La propiedad industrial es utilizada principalmente para estimular la innovacin, el diseo y la creacin de tecnologa. En esta categora se incluyen las invenciones (protegidas por patentes), los dibujos y modelos industriales y los secretos comerciales o informacin no divulgada. 4. Con las patentes se protegen las invenciones, estas son el producto o proceso que ofrece una nueva manera de hacer algo, o una nueva solucin tcnica a un problema. El inventor deber ser mencionado como tal en la patente que se conceda y en las publicaciones y documentos oficiales relativos a ella, salvo renuncia expresa por escrito, segn lo establece en nuestro derecho la Ley N 17.164 (sobre Patentes de Invencin, Modelos de Utilidad y Diseos Industriales). 5. Por su parte, tambin tenemos la proteccin de las marcas. Una marca es un signo distintivo: a) que indica que ciertos bienes o servicios han sido producidos o proporcionados por una persona o empresa determinada, b) que ofrece proteccin a su titular, garantizndole el derecho exclusivo a utilizarla para identificar bienes o servicios, o a autorizar a un tercero a usarla a cambio de un pago.
Cmo respetar estos derechos?

Una de las formas de encontrar identificado el Derecho de Autor es con la palabra inglesa Copyright, que alude exclusivamente al derecho de copia. El titular puede impedir a otra persona efectuar copias de sus obras y ste es uno de los derechos amparado por la legislacin. Por ende, para la utilizacin de este tipo de obras es necesario contar con la autorizacin del titular de los derechos, o de lo contrario ampararse en alguna de las excepciones, como por ejemplo el Derecho de Cita, que permite utilizar un prrafo sin autorizacin, indicando la fuente.
Cuando nos referimos a invenciones, el titular de la patente puede dar su permiso o licencia a terceros para utilizar la invencin de conformidad con los trminos establecidos de comn acuerdo.
Recomendaciones
A la hora de gestionar o de crear un sitio web debemos asegurarnos: 1. Que los nombres de dominio elegidos (bienes o signos distintivos diferentes de las marcas y que analizaremos oportunamente), no infrinjan los derechos de marcas vigentes. 2. Que los procedimientos o la tecnologa utilizada en la creacin del sitio no vulneran los derechos de autor. 3. Que el contenido del sitio no viola derechos de autor de terceros. Para ello se debera solicitar las autorizaciones pertinentes, salvo para los siguientes casos: Si utiliz el Derecho de Cita. Si el contenido est publicado con Licencia Creative Commons. Cuando hay una autorizacin expresa del autor a utilizar o reproducir el contenido. De todas formas hay que recordar que pasados 50 aos desde la muerte del autor, las obras pasan a ser parte del dominio pblico. 4. Que se debe proteger adecuadamente los activos de propiedad intelectual propios del organismo, a travs de medidas de seguridad informtica, clusulas de confidencialidad, clusulas de derecho de autor, etc. 5. Que se deben incluir avisos dirigidos a los visitantes del sitio que pretendan tomar prestado ciertos contenidos del mismo. En este caso el organismo debe definir y puede optar entre prohibir la reproduccin de los contenidos del sitio en base a la proteccin de los Derechos de Autor; o autorizar la reproduccin en los trminos ya indicados, o sea citando al autor y la fuente. 6. Que aquellos organismos que realicen cuestiones relativas a transacciones internacionales de comercio electrnico, debern incluir
una clusula de jurisdiccin competente y ley aplicable en su sitio web, o de lo contrario una clusula de arbitraje, en cuyo caso las partes ante un conflicto debern recurrir a este sistema. 7. Que, si para disear el sitio web, el organismo utiliza un consultor o una empresa, es conveniente examinar las disposiciones del contrato relativas a la titularidad y a los derechos de propiedad, tanto respecto al diseo, como respecto al contenido del mismo. Tambin hay que asegurarse que todos los elementos protegidos por la propiedad intelectual y que sean utilizados, sean propiedad de esa empresa o consultor, o que de lo contrario se hayan obtenido las licencias o autorizaciones necesarias. Este es un buen mecanismo para evitar demandas por infracciones en el futuro. 8. Que, tambin es conveniente, evitar el uso indebido de metaetiquetas, utilizar el sistema de enlaces con prudencia y solicitar la autorizacin necesaria para usar contenidos de marcos o ventanas, que no sean propios del sitio.
Cmo implementar las recomendaciones?

Hay diferentes formas de implementar las recomendaciones segn sea el caso y el diseo de su portal. Lo importante es que los usuarios puedan acceder fcilmente a la informacin y a toda clusula que tenga por objetivo proteger diversos derechos.
Eleccin de nombres de dominio

Al elegir el nombre del dominio para su portal, debe consultar que no se encuentra registrado. Qu posibilidades existen para realizar esto? Para los dominios .gub.uy, debe consultar en la pgina del SECIU www.rau.edu.uy
Para los dominios .com.uy, debe consultar en la pgina de ANTEL. www.antel.com.uy
All coloque el nombre del dominio que desea utilizar y verifique si ya est registrado. Nota: En el caso que elija un nombre para su dominio que coincida con marcas muy conocidas, por ejemplo Polo, Yahoo, deber tener presente que pueden generarse conflicto de intereses y los titulares de esas marcas podran reclamar sus derechos.
Tecnologa a utilizar
Los productos o herramientas utilizadas para el desarrollo del portal no deben vulnerar los derechos de autor. En caso de que necesite desarrollar un proyecto de estas caractersticas y no disponga de los medios necesarios para cumplir con esto, hay herramientas de uso libre disponible en la Web. Por ejemplo: Liferay, Drupal, Plone, Joomla.
Autorizaciones de los contenidos

Cuando deba incorporar contenidos pertenecientes a terceros deber solicitar la autorizacin correspondiente. En algunos casos en el mismo material se indica la forma de realizar dicho pedido. Por ejemplo una direccin de mail o un telfono, pero la respuesta debe ser siempre por escrito.
Citar autores
Si utiliz el Derecho de Cita, debe tener presente que existen diferentes formas de hacerlo correctamente.
Como citar bibliografas

Fuente: Pgina APRENDE A CITAR CORRECTAMENTE TUS TRABAJOS... en http://iteso.mx/~abby/citasbibliograficas.htm (Fecha de acceso: 24/11/2009)
Fuente Libro con un solo autor
Forma de hacerlo correctamente APELLIDO AUTOR, Nombre, Ttulo, Editorial, Ciudad, ao. Autor se inicia con apellido en VERSALES, nombre en altas y bajas. Ttulo slo 1er letra con mayscula, excepto en nombres propios;
Editorial no se anota la palabra editorial o editores
Ejemplo
ORNELAS, Carlos. El sistema educativo mexicano, Fondo de Cultura Econmica, Mxico, sptima reimpresin, 2000.
Libro con dos autores
APELLIDO, Nombre y APELLIDO,
STEIN, Brbara y STEIN, Stanley, La herencia 1988.
Nombre, Ttulo, Editorial, Ciudad, ao. colonial de Amrica Latina, Siglo XXI, Mxico,
Libro con ms de
APELLIDO Nombre del primer autor,
HERNNDEZ, Jos, et. al., Antologa Potica, El
Fuente dos autores Libro con autor corporativo
Forma de hacerlo correctamente et al., Ttulo, Editorial, Ciudad, ao. El corporativo se anota como autor.
Ejemplo
Ateneo, Buenos Aires, 1995. ASOCIACIN NACIONAL DE INSTITUCIONES DE EDUCACIN SUPERIOR, La educacin superior en Mxico y Amrica Latina, ANUIES, Mxico, 1996.
Libro que forma parte de una serie
La serie se cita entre parntesis ( ) despus de la Ciudad
SNCHEZ, Margarita, Organizacin del pensamiento, Trillas, Mxico, (Aprende a Pensar, nm.2), 1993.
Artculo en revista
Autor, Ttulo artculo, en Ttulo de la Revista, Editor, Ciudad, vol., nm., da mes y ao, Pgina Si no hay autor se inicia con el Ttulo del artculo
MAGAA, Omar, La tarea educativa fuera del aula, en Magis, ITESO, Guadalajara, nm. 364 julio-agosto 2003. p.19.
Artculo en libro
Autor, Ttulo del artculo, en Coordinadores del libro (coords.), Ttulo del libro, Editor, Ciudad, Ao, Pgina.
GUERRERO ANAYA, Luis y GONZALEZ J., Beatriz, Reflexiones sobre la cultura, en ALONSO, Jorge y GARCIA, Juan (coords.), Poltica y Regin, CIESAS, Mxico, 1990, Pgina. 252-285 GALLEGOS, Elena, El ocaso de un triunfador, en 2000, contraportada, Pgina. 6-7
Artculo en peridico Autor, Ttulo del Artculo en Ttulo ao, seccin si la paginacin cambia, Pgina. Enciclopedia AUTOR, si lo tiene, Ttulo, Editor, Ciudad, tomo, ao, Pgina. Fuente electrnica cambiante
del peridico, Ciudad, nm., da, mes, La Jornada, Mxico, nm. 5509, 5 de enero de
Enciclopedia Salvat, Salvat, Mxico, tomo 8, 1982, Pgina. 796.
AUTOR, Ttulo, fecha, lugar, direccin BETANCOURT M., Julin y VALADEZ, Dolores de acceso, (Fecha de acceso: fecha en que se visit)
Jerome Bruner: uno de los precursores de los estudios sobre estrategias cognitivas, 2002, (Fecha de acceso: 29 de Abril de 2003)
http://educacion.jalisco.gob.mx/consulta/educ ar/06/6betan.htm Fuente electrnica no cambiante, sin referencia impresa AUTOR, Ttulo, en direccin de acceso, (Fecha de acceso: fecha en que se visit)
POSADA, Jorge Jairo, Jerome Bruner y la educacin de adultos, en
http://investigacion.ilce.edu.mx/dice/diplomad o/rtf/jbruner.rtf, (Fecha de acceso: 29 de Abril de

2003.)
Fuente Fuente electrnica no cambiante con referencia impresa.
Forma de hacerlo correctamente AUTOR, Ttulo, en Revista o Diario, de acceso, (Fecha de acceso: fecha de visita)
Ejemplo
ISLAS, Mariana, Proponen escuelas para crear Guadalajara,
nm. fecha, Pgina. Ciudad, direccin bibliotecas en Mural, 22 de Ago. de 2003 , http://www.mural.com/cultura/articulo/293478/ #inicio (Fecha de acceso: 25 de Agosto de 2003)
Discos compactos
Ttulo de la obra, editor, disco compacto, fecha.
Encarta 2000, Microsoft Corporation, disco compacto, 2003.
Derechos de autor de imgenes

En el caso de utilizar imgenes protegidas por Derechos de Autor debe solicitarse la autorizacin del autor. Si las imgenes se obtienen de bancos de imgenes libres no es necesario el consentimiento.
Proteger activos de Propiedad Intelectual

Se debe proteger adecuadamente los activos de propiedad intelectual propios del organismo, a travs de medidas de seguridad informtica, clusulas de confidencialidad, clusulas de derecho de copia (Copyright), etc.
Derecho de propiedad intelectual del portal

Es conveniente que en la pgina de Inicio o portada de su sitio web tenga un aviso referido a los derechos de propiedad del sitio.
Ejemplo
Ministerio de Justicia Este ejemplo est aplicado en el sitio del Ministerio de Justicia de Espaa: www.mjusticia.es 2008 ANTEL, LA EMPRESA DE TELECOMUNICACIONES DE LOS URUGUAYOS Este ejemplo est aplicado en el sitio de ANTEL: www.antel.com.uy/
2009 | Intendencia Municipal de Montevideo | Todos los derechos reservados Otra forma es colocar Todos los derechos reservados, tal como realiza la Intendencia Municipal de Montevideo en el pie de su portada: www.montevideo.gub.uy
Clusulas a incluir en el portal

Es conveniente en la portada del sitio colocar un vnculo a una pgina que contenga todas las clusulas que expliquen las polticas de propiedad intelectual adoptadas en el sitio. En algunos portales podr observar que aparece en la parte inferior de la pgina un vnculo identificado como Aviso Legal, o Condiciones legales.
Ejemplo
www.nl.gob.mx www.artelista.com
A continuacin proponemos una serie de modelos de clusulas con la idea de que puedan ser tomadas como ejemplos.
Modelo de clusulas de Derechos de Autor

Para proteger los derechos de los organismos y sus proveedores: Derecho de Autor: Todo el contenido incluido en el presente sitio, como los textos, grficos, dibujos, logotipos, conos, imgenes, fragmentos sonoros, descargas digitales, recopilaciones de datos y programas informticos, es propiedad de <Nombre del Organismo>, o de sus proveedores de contenidos y est protegido por la legislacin vigente en materia de derecho de autor. La compilacin de todo el contenido del presente sitio es propiedad exclusiva de <Nombre del Organismo>, y est protegida por la legislacin vigente en materia de derechos de autor. Todos los programas utilizados en el presente sitio son propiedad de <Nombre del Organismo>, o de sus proveedores de programas informticos y tambin estn protegidos por la mencionada legislacin.
Para no autorizar la reproduccin de los contenidos: Autorizacin del titular de los Derechos de Autor. Si Usted desea puede usar este sitio web pero est prohibido reproducir, distribuir, modificar, exhibir, preparar obras derivadas, volver a publicar o utilizar de otra manera el contenido del presente sitio sin el consentimiento previo por escrito de <Nombre del Organismo>
Para autorizar el uso de los contenidos: Derecho de uso. Los contenidos de este sitio pueden ser usados siempre que sea sin nimo de lucro, con finalidad educativa o para la difusin del conocimiento y de promocin de la cultura.
Para indicarle a un autor como reclamar sus derechos: Aviso a los titulares de Derechos de Autor: Si usted posee derechos de propiedad intelectual y cree que su material ha sido publicado o distribuido inadecuadamente por medio del presente sitio, le solicitamos que lo notifique inmediatamente a <Nombre del Organismo>
Transparencia
A travs de ley de Acceso a la Informacin Pblica (Ley 18.381 del 17 de octubre de 2008) se reconoce y garantiza el derecho de todas las personas a acceder a la informacin que produce y controla el Estado. Hay dos modalidades para lograr esto que se identifican como: Transparencia Activa, que consiste en que el organismo brinda informacin a travs de su sitio web, o a travs de otros canales de comunicacin como folletos, Cd, etc. Transparencia Pasiva, que consiste en la posibilidad que cualquier persona se presente ante un organismo y solicite determinada informacin.
Fuente: Propiedad del CIRD en el marco del Programa de Apoyo a las Iniciativas Ciudadanas, PAIC
Cmo garantizar la transparencia de la funcin pblica?

El contenido es uno de los puntos ms importantes a considerar en el desarrollo de los sitios web de los organismos pblicos, se debe garantizar el acceso a la informacin y promover la transparencia de la gestin pblica. La promocin del gobierno abierto es uno de los estndares internacionales ms importantes en materia de acceso a la informacin, e implica la promocin de una cultura de transparencia de toda la administracin pblica. 15 La transparencia no solo pasa por publicar muchos contenidos de la organizacin, sino que estos a su vez deben estar disponibles y fciles de encontrar por los usuarios de la web. Para lograr esto es necesario incorporarlo en la etapa de diseo de los bocetos del portal, donde se disea la arquitectura de la informacin. Deben presentarse como un servicio ms a la ciudadana: debe ser de calidad, clara, ordenada, dirigida fundamentalmente a las personas en general, en un lenguaje simple, directo y afable, que debe indicar la relacin de cercana que se pretende fomentar entre el organismo y el usuario.
Qu se debe publicar en los sitios web?

El art. 5 de la Ley N 18.381 de Acceso a la Informacin Pblica, obliga a publicar en todos los sitios web de organismos pblicos, sean estatales o no, la siguiente informacin mnima: su estructura orgnica y sus autoridades, las facultades y cometidos de cada unidad administrativa, los servicios que brinda y los trmites que hay que hacer para acceder a ellos, las remuneraciones de los funcionarios (sueldos y compensaciones), la ejecucin presupuestal, las rendiciones de cuentas y las auditoras, las concesiones, licitaciones, permisos o autorizaciones (adjudicatarios y montos),
Tomaremos como base, adems de nuestra legislacin, los aportes recogidos en la Gua para el Desarrollo de Sitios Web de la Administracin Pblica Federal, realizada en el ao 2007 por el Sistema Internet de la Presidencia, Mxico. (www.sip.gob.mx).
15
las estadsticas y datos que tengan relacin con sus cometidos, y dems datos necesarios para que los ciudadanos puedan contactarse y solicitar informacin (mesa de entrada, correo electrnico, telfonos).
Cmo dar publicidad por medios electrnicos a las compras estatales?

De acuerdo con la normativa vigente, toda institucin pblica debe enviar la informacin de sus licitaciones, compras directas, adjudicaciones, ampliaciones de las mismas y reiteracin de gasto si las hubiere, a efectos de su publicacin en el sitio web www.comprasestatales.gub.uy En el art. 5 de la Ley N 18.381, tambin establece que se debe informar a travs de las pginas web de los organismos pblicos, sean estatales o no, acerca de los llamados y los resultados de las concesiones, licitaciones, permisos o autorizaciones (adjudicatarios y montos). Es importante que el ciudadano ubique la informacin en el sitio web de cada organismo, ya sea en forma directa o a travs de un vnculo que lo conduzca directamente al sitio de compras estatales. Es importante tener en cuenta que adems deber estar disponible la informacin referida a las adquisiciones que surgen de partidas presupuestales provenientes de convenios con organismos internacionales o que se gestionen a travs de stos. La informacin que debe estar accesible al pblico para cada adquisicin, refiere a los pliegos de bases y condiciones particulares de los procedimientos licitatorios que representen gastos de funcionamiento o de inversin, y las resoluciones que dispongan la adjudicacin en dichos procedimientos, as como las que declaren desiertas o dispongan el rechazo de todas las ofertas presentadas.
Recomendaciones para informar a travs de las pginas web

1. La informacin publicada deber estar fundamentada en los siguientes principios: Calidad: deber ser informacin pertinente, til y adecuada, tanto para satisfacer el derecho de las personas a tener acceso y conocimiento, como para promover la transparencia del organismo. Veracidad: deber ser informacin veraz y ajustada a la realidad. Oportunidad: deber informarse en forma permanente y actualizada.
2. Promover la participacin: Los organismos deberan realizar peridicamente mediciones de satisfaccin de los ciudadanos respecto a la usabilidad de los sitios, a efectos de mejorar los mismos y los servicios que ofrecen. Para ello, es conveniente establecer un espacio de consulta, de encuesta o foros, que permita identificar los problemas o dificultades con que se encuentran los usuarios al utilizar el sitio.
Ejemplo
Existen diferentes niveles de desarrollo en los instrumentos de participacin implementados en los sitios web del estado. A continuacin colocamos dos ejemplos: Intendencia Municipal de Montevideo y el Estado de Nuevo Len en Mxico. En la Intendencia Municipal de Montevideo podemos encontrar el Buzn Ciudadano.
http://www.montevideo.gub.uy/institucional/formularios-de-contacto
En el Estado de Nuevo Len existen otros mecanismos de participacin ciudadana, tales como chat, encuestas y foros.
http://www.nl.gob.mx/?P=participacionciudadana
3. Incluir en su sitio web vnculos a otros organismos relacionados con sus cometidos y a los rganos jerrquicamente superiores. 4. Informar a los visitantes de los cambios que se realicen en el sitio. De esta forma, se facilita el acceso, la bsqueda y la localizacin de la informacin. Cuando se cambie la direccin del sitio o de alguna pgina (URL), deber publicarse un enlace que redireccione al usuario a la nueva URL del sitio. 5. Se debe publicar la ltima fecha de actualizacin de los sitios, ya sea dentro de sus contenidos, como en la pgina principal. Con este dato se le indica al usuario que la informacin est actualizada y se le brinda certidumbre. 6. Los organismos que cuentan con trmites o servicios en lnea, debern ofrecer un acceso sencillo y confiable. Estos trmites deben ser transparentes, integrales, rpidos, y sobre todo contar con la caracterstica del autoservicio. Para ello, debern figurar en forma destacada o visible en la pgina de inicio. Cuando el servicio en lnea sea nuevo, se debera agregar una leyenda que diga nuevo. 7. Debern adoptarse las medidas necesarias para garantizar la seguridad de los datos de aquellos usuarios que realizan trmites y/o utilizan servicios en lnea. Estos datos debern viajar a travs de protocolos seguros y de acuerdo a acuerdo a los principios previstos en la Ley N 18.331 de Proteccin de Datos Personales y Accin de Habeas Data. 8. El organismo deber designar a un responsable de la informacin disponible en la pgina web. Es importante destacar la diferencia entre el responsable de la informacin y el responsable del sitio web, que pueden coincidir en la misma persona o no. El responsable de la informacin es el encargado de proveer la informacin que se publica en el sitio web. 9. En caso de tener dudas o necesitar asesoramiento dirigirse a: www.informacionpublica.gub.uy
Solicitudes de Informacin a travs del Sitio

El derecho de acceso a la informacin pblica debe ser satisfecho de la manera ms rpida, sencilla y eficiente posible. Una forma de orientar al solicitante es difundir a travs de su sitio web el procedimiento mediante el cual puede realizar el trmite. Existen diferentes formas de instrumentar el procedimiento, una de ellas puede ser tener la solicitud en lnea y otra por ejemplo podra ser publicar los formularios de solicitud para que cualquier usuario los pueda descargar y utilizar. A continuacin proporcionamos un modelo de Formulario de Solicitud de Acceso a la Informacin Pblica y otro de Respuesta del Organismo. Los mismos pueden ser utilizados como base para los organismos en caso de tener uno diseado.
Ejemplo
Modelo de solicitud de acceso a la informacin pblica

FORMULARIO DE SOLICITUD DE INFORMACIN PBLICA
Lugar y Fecha de la Solicitud Organismo al que hace la solicitud Ciudad/Localidad de la Solicitud Fecha de la Solicitud
Datos del Solicitante Nombre Completo Direccin
Telfono Correo Electrnico
Informacin Solicitada Indique a que informacin pblica desea acceder de acuerdo a lo previsto en la Ley N 18.381 de Acceso a la Informacin Pblica: <describir la informacin y si se poseen, mencionar todos los datos que permitan la bsqueda y faciliten el acceso>
Formato de la Respuesta Indique el formato en que desea recibir la informacin solicitada: <Ejemplo: pueden ser fotocopias, CD, mail con archivos adjuntos>
Modelo de nota de respuesta a una solicitud de acceso a la informacin pblica

1er. Caso: Cuando la informacin est disponible <Ciudad/Localidad>, <da> de <mes> de <ao>. En respuesta a su solicitud de acceso formulada con fecha <fecha de la solicitud> referida a la siguiente informacin <transcribir toda la informacin solicitada>, el organismo <Nombre del organismo>, ha resuelto que se le haga entrega de la informacin que ha solicitado. Srvase pasar por nuestras oficinas ubicadas en <direccin>, a partir de <fecha > en el horario de <horario de atencin al pblico> a efectos de retirar copia de la informacin solicitada. La misma ser entregada en <formato de entrega>. El costo de la reproduccin es < costo de la reproduccin del material que deber abonar al momento del retiro> ....................................................... Firma del Funcionario
2do. Caso: Cuando informacin que se solicita es reservada o confidencial.
<Ciudad/Localidad>, <da> de <mes> de <ao>. En respuesta a su solicitud de acceso formulada con fecha <fecha de la solicitud> referida a la siguiente informacin <transcribir toda la informacin solicitada>, el organismo <Nombre del organismo>, ha resuelto que la misma no le sea entregada, en vista de que se trata de informacin clasificada como <indicar si es reservada o confidencial>. Adjuntamos la resolucin que establece el fundamento legal y dems datos relacionados. ....................................................... Firma del Funcionario Nota: En vista de que la ley establece plazos especiales, estas comunicaciones debern estar acompaadas de formularios de confirmacin de hora y fecha de recibido, para el caso de que la comunicacin haya sido realizada por correo electrnico.
Privacidad
Debemos establecer un justo equilibro entre transparencia, acceso a la informacin pblica como un derecho y el derecho a la proteccin de los datos personales. Al enfrentarse a un proyecto de desarrollo de un portal debe tener en cuenta estos conceptos y garantizar ambos derechos. El art. 10 de la Ley N 18.381 de Acceso a la Informacin Pblica, considera como una de las excepciones al acceso, la informacin confidencial que posee el organismo de acuerdo a los requisitos que exige la norma. Dentro de esta informacin se ubican los datos personales, que de acuerdo a la Ley de Proteccin de Datos Personales (Ley N 18.331 del 11 de agosto de 2008), requieren previo consentimiento informado para su tratamiento. La Ley N 18.331 indica que, en principio, todos los datos personales requieren previo consentimiento informado, excepto que: Deriven de fuentes pblicas de informacin, tales como registros o publicaciones en medios masivos de comunicacin. Se recaben para funciones propias del Estado o en virtud de una obligacin legal. Provengan de listados que en el caso de personas fsicas refieran a: nombres y apellidos, documento de identidad, nacionalidad, domicilio y fecha de nacimiento y en el de personas jurdicas a: razn social, nombre de fantasa, registro nico de contribuyentes, domicilio, telfono e identidad de las personas a cargo de la misma. Se traten como consecuencia de una relacin contractual, cientfica o profesional del titular del dato y resulten necesarios para su desarrollo o cumplimiento.
Hay que tener presente adems, que en el marco de la Ley de Proteccin de Datos Personales, se protegen especialmente los denominados datos sensibles que sin lugar a dudas deben clasificarse como confidenciales. Los datos sensibles son los que revelan origen racial y tnico, preferencias polticas, convicciones religiosas o morales, filiacin sindical e informacin referente a la salud o a la vida sexual.
Por otra parte, los datos relativos a la salud solo podrn ser recolectados y tratados por los establecimientos sanitarios y los profesionales vinculados a esa rama cuando los pacientes hayan acudido a stos, respetndose siempre el secreto profesional y las normas especficas en la materia. Queda prohibida de manera expresa la formacin de bases de datos que almacenen informacin que directa o indirectamente revele datos sensibles. Los organismos pueden tratar datos sensibles de sus funcionarios en la medida en que ello sea necesario para cumplir con sus funciones o para el otorgamiento de beneficios (prestaciones, licencias, afiliacin sindical) y que los mismos hayan sido recabados con el consentimiento del titular. La informacin confidencial podr ser accedida y utilizada solamente por usuarios debidamente autorizados y bajo las condiciones establecidas por las normas que la protegen. El acceso deber estar protegido por importantes controles de seguridad. Los responsables, quienes tuvieran acceso, o quienes intervengan en el tratamiento de esos datos, debern guardar estricta reserva.
Principales conceptos
Derechos que garantiza la Ley de Proteccin de Datos Personales
Derecho de informacin frente a la recoleccin de datos

Cuando se recaban datos personales a travs de las diferentes herramientas de los sitios web, se deber informar claramente y en forma previa: para qu sern usados los datos, quines pueden ser sus destinatarios, la opcin de responder o no, especialmente respecto a los datos sensibles (vida sexual, origen racial y tnico, filiacin sindical o poltica y creencias religiosas). Esto deber ser implementado a travs de clusulas que debern ser visualizadas por el usuario antes de brindar la informacin.
Derecho de acceso
Toda persona tiene derecho a que se le brinde la informacin que sobre ella se encuentre en una base de datos pblica o privada. Para ello ser necesaria su identificacin a travs del documento de identidad o con un poder.
Derecho de rectificacin, actualizacin, inclusin o supresin

Cuando una persona se entere que sus datos personales contenidos en una base de datos son errneos, falsos, desactualizados o debiendo estar incluidos no lo estn, podr solicitar ante el responsable de la base de datos su rectificacin, actualizacin, inclusin o supresin.
Obligaciones en relacin con la recoleccin y tratamiento de datos personales

Se deben ajustar a los siguientes principios: Legalidad: para que una base de datos sea legtima, deber inscribirse en la Unidad Reguladora y de Control de Datos Personales (URCDP) y cumplir con los requisitos establecidos en la Ley. Veracidad: los datos personales debern ser veraces, exactos y actualizados. Finalidad: no pueden utilizarse los datos personales para fines distintos a aquellos para los cuales fueron recolectados. Previo consentimiento informado: el tratamiento de datos personales ser legtimo cuando el titular haya prestado su consentimiento en forma previa, libre, expresa e informada, salvo las excepciones establecidas en la Ley. Seguridad de los datos: el responsable de la Base de Datos debe garantizar la seguridad y confidencialidad de los datos personales, adoptando las medidas necesarias. Reserva: quienes utilicen datos personales en sus actividades no podrn difundirlos a terceras personas. Responsabilidad: el responsable de la Base de Datos es responsable por el incumplimiento de la Ley.
Recomendaciones
1. Se deben introducir una serie de avisos o clusulas que establezcan qu tipo de informacin de los visitantes es recolectada, cmo ser utilizada y cmo y cundo ser eliminada. 2. Cada vez que a travs de la pgina web, se soliciten datos personales de los usuarios mediante formularios de contacto, se deber colocar un aviso o clusula que apunta a indicar la finalidad de dicha recoleccin, el nivel de seguridad y su utilizacin en el marco de lo preceptuado por la Ley N 18.331. 3. Tambin podrn proveerse mecanismos alternos al sitio web para el envo de datos personales (correo electrnico o correo postal). 4. En aquellos casos, en que se deba publicar informacin relacionada con funcionarios, en cumplimiento con las disposiciones de la Ley N 18.381 de Acceso a la Informacin Pblica, es recomendable la elaboracin de versiones pblicas de dicha informacin. Esto quiere decir que debera evitarse la publicacin de aquellos datos personales que no se relacionan directamente con el objetivo que persigue la norma, por ejemplo, estado civil, edad, domicilio particular, telfono particular, correo electrnico personal. 5. Aquellos organismos pblicos que cuenten con bases de datos personales debern inscribir las mismas en el Registro de Bases de Datos Personales que lleva la Unidad Reguladora y de Control de Datos Personales (Art. 29 de la Ley N 18.331) 6. En caso de tener dudas o necesitar asesoramiento dirigirse a: www.protecciondedatos.gub.uy
Cmo implementar las recomendaciones?

En algunos casos debern incluirse clusulas que informen y garanticen los derechos de los titulares de los datos, en otros casos podr difundir los procedimientos y colocar a disposicin de los usuarios los formularios que le permiten ejercer sus derechos. A continuacin se ofrecen una serie de modelos que podrn tomarse como ejemplos para implementar en sus sitios web.
Solicitud de consentimiento
1er. Caso: Para recabar datos personales de un usuario Previo Consentimiento Informado: De conformidad con la Ley N 18.331, de 11 de agosto de 2008, de Proteccin de Datos Personales y Accin de Habeas Data (LPDP), los datos suministrados por el usuario quedarn incorporados en una base de datos, la cual ser procesada exclusivamente para la siguiente finalidad: ..................(indicar finalidad). Los datos personales sern tratados con el grado de proteccin adecuado, tomndose las medidas de seguridad necesarias para evitar su alteracin, prdida, tratamiento o acceso no autorizado por parte de terceros que lo puedan utilizar para finalidades distintas para las que han sido solicitados al usuario. El rgano responsable de los datos es.............................(indicar el nombre) y la direccin donde el interesado podr ejercer los derechos de acceso, rectificacin, actualizacin, inclusin o supresin, es ..............................(indicar direccin), segn lo establecido en la Ley N 18.331. 2do. Caso: Obtener el consentimiento para la realizacin de transferencia al extranjero de datos personales Los datos personales recogidos sern transferidos a........................(indicar pas y organismo o empresa) con la finalidad de .................(indicar la finalidad) ..................y no podrn ser utilizados para otros fines diferentes o incompatibles con los ya expresados. El rgano responsable de los datos es.............................(indicar el nombre) y la direccin donde el interesado podr ejercer los derechos de acceso, rectificacin, actualizacin, inclusin o supresin, es ..............................(indicar direccin), segn lo establecido en la Ley N 18.331.
Solicitud de Acceso a los datos personales

FORMULARIO PARA EJERCER EL DERECHO DE ACCESO
Fecha y lugar de la Solicitud Fecha Ciudad/Localidad
Datos del Responsable de la base de datos Nombre del responsable Organismo Pblico Direccin Telfono Departamento
Datos del Titular Nombre del Titular Direccin Ciudad/Localidad Telfono Correo Electrnico Cdula de Identidad Ejerce por este medio el derecho de acceso, conforme a lo previsto en el artculo 14 de la Ley N 18.331 de Proteccin de Datos Personales y Accin de Habeas Data de 11 de agosto de 2008, solicitando: A) Se me proporcione en forma gratuita toda la informacin que sobre mi persona se encuentre en su/s base/s de datos o registro/s, en el plazo mximo de cinco (5) das hbiles a contar desde la recepcin de esta solicitud. Vencido dicho plazo sin que el pedido sea satisfecho o si fuera denegado por razones no justificadas, quedar habilitada la accin de Habeas Data. B) La informacin debe ser amplia y suministrada en forma clara, exenta de codificaciones y en su caso acompaada de una explicacin, en lenguaje accesible. C) Se me remita la informacin de acuerdo a los datos arriba suministrados: Personalmente Telefnicamente Correo Electrnico Otro
(Aclarar).. Firma del solicitante
Nombres de dominio
Qu son y cmo se registran?
Los nombres de dominio pueden ser considerados bienes, y por lo tanto tienen valor y son susceptibles de ser negociados. Sin embargo se discute a nivel jurdico si deben ser considerados signos distintivos o no. Hay varias posiciones al respecto. Precisamente una de ellas los ha considerado como signos distintivos sui generis, ya que si bien por s mismos no contaran con un rgimen jurdico propio, podran sin embargo, subsumirse dentro de algunas de las categoras previstas por el ordenamiento (marcas, nombres personales, etc.), cuando de su utilizacin se derive una vinculacin entre ambos elementos16. En definitiva, para el caso de los organismos, dependencias o reparticiones de la administracin pblica o del Estado, es caracterstico que el usuario, al ver los nombres de dominio que los identifican, reconozca que se trata de uno u otro. En nuestro pas, actualmente los nicos dominios de nivel superior que se utilizan son los siguientes: gub (gobierno), edu (instituciones de enseanza), com (empresas comerciales), mil (organizaciones militares), net (proveedores de red), y org (entidades sin fines de lucro). Para registrar nombres de dominio de organismos pblicos, estatales o no, es necesario ingresar a www.rau.edu.uy. A travs de este sitio se gestiona el registro de dominio UY y es un servicio brindado por la Universidad de la Repblica, a travs del SeCIU (Servicio Central de Informtica Universitario), a cualquier organizacin o persona, que desee registrar nombres de dominios en Internet bajo el cdigo del pas correspondiente a Uruguay. En cambio, el dominio .com se gestiona ante ANTEL, pues el SeCIU en el ao 1991 cedi el registro del mismo a este organismo pblico.
16
Se toman como base los conceptos que se ubican en el libro Lecciones de Derecho Telemtico del Dr. Carlos Delpiazzo y la Dra. Mara Jos Viega
Avisos Legales
En todo sitio web debe existir un espacio donde un usuario pueda encontrar las condiciones de uso y los avisos legales correspondientes. En estas clusulas y avisos el organismo responsable del sitio web deber incluir: Condiciones de uso Exoneracin de responsabilidad Obligaciones del usuario del portal Legislacin aplicable y jurisdiccin competente Poltica de Propiedad Intelectual Poltica de Proteccin de datos Poltica de Seguridad
Captulo V
Seguridad de un portal
Captulo V Seguridad del portal | 261
Seguridad del Portal

Los portales WEB se ven expuestos a un creciente nmero de amenazas y vulnerabilidades que pueden afectar la imagen institucional, la disponibilidad de los servicios brindados, la integridad y la confidencialidad de la informacin que se trasmite a travs del mismo, entre otros. En este captulo se presenta un conjunto de controles para mitigar los riesgos de seguridad a los cuales se ven expuesto los portales WEB. Los controles expuestos no constituyen una lista exhaustiva y el organismo puede considerar que se necesitan controles adicionales. Los controles presentados en este captulo implican funciones de hardware y software, pero cabe sealar que la seguridad que puede lograrse a travs de estos medios tcnicos es limitada y por esto debera apoyarse en una gestin y en procedimientos adecuados. Los controles seleccionados deberan estar alineados con las buenas prcticas de seguridad definidas por el organismo y en particular con la Poltica de Seguridad del mismo (ver Poltica de Seguridad modelo de AGESIC www.agesic.gub.uy). En esta oportunidad hemos seleccionado un conjunto de controles enfocados en la estructura del sitio y en la confidencialidad, integridad y disponibilidad de la informacin que albergan.
Proteccin contra divulgacin de informacin no autorizada

No necesariamente toda la informacin que ponemos a disposicin a travs de nuestro portal es de carcter pblico, en consecuencia debemos proteger la divulgacin no autorizada de la misma. Podemos contar, por ejemplo, con secciones reservadas para personal autorizado y servicios interactivos que realicen trasiego de datos sensibles que requieren adecuada proteccin.
Captulo V Seguridad del Portal | 262
Adicionalmente nuestros portales pueden revelar, involuntariamente, informacin sobre su configuracin, su funcionamiento interno, e incluso violar la privacidad de personas fsicas. Los atacantes pueden usar estas vulnerabilidades para obtener datos delicados o realizar ataques ms serios.
Proteccin contra Robots No ponga a disposicin ms de lo necesario

Dado el gran nmero de sitios Web que pueblan Internet la nica forma viable de realizar bsquedas de contenidos pas a ser los motores de bsqueda y sin duda debe ser el mecanismo por el cual los usuarios acceden mayoritariamente a nuestro portal. Para alimentar a estos motores de bsqueda se utilizan los llamados robots17, programas generados por los distintos buscadores que atraviesan la estructura de un sitio Web recuperando los enlaces del mismo. No necesariamente toda la informacin disponible a travs de nuestro portal tiene carcter pblico, podemos desear preservar la confidencialidad de ciertos directorios de nuestro sitio destinados slo para uso interno o privilegiado. Para evitar que los robots identifiquen, analicen y registren estos directorios debemos generar un archivo de texto llamado robots.txt el cual debemos alojar en el directorio raz de nuestro portal. Cada vez que un robot visita un sitio, primero revisa si existe ese archivo, si no lo encuentra, registra la pgina en el motor de bsqueda que lo haya enviado; si lo encuentra, analiza su contenido.
Ejemplo
Fuente: basado en el ejemplo presentado en la Gua de pruebas de OWASP ver.3.0 [3]
A continuacin, se presenta a modo de ejemplo, el archivo robots.txt del portal gubernamental del Estado de Nuevo Len en Mxico: http://www.nl.gob.mx
http://www.nl.gob.mx/robots.txt : # Robots.txt file from http://www.nl.gob.mx # # Bans from tesoreria #
17
Los robots tambin son conocidos bajo los trminos crawler o spider web
Captulo V Seguridad de un portal | 263
# Disallow /tesoreria/
User-agent: * Disallow: /tesoreria/ Disallow: /stats/ Disallow: /servicios/ Disallow: /protegido/ Disallow: /skins/ Disallow: /Eventos/ Disallow: /buscador/ Disallow: /apps/ Allow: /protegido/buscador/
La directiva User-Agent hace referencia al robot de bsqueda. Por ejemplo, con User-Agent: Googlebot se har referencia al robot de bsqueda de Google, mientras que utilizando User-Agent: * como en el ejemplo anterior, se aplicarn las reglas a todos los robots de bsqueda: La directiva Disallow especifica que recursos no debern ser inspeccionados por los robots. En el ejemplo anterior, se prohben los siguientes directorios:
... Disallow: /tesoreria/ Disallow: /stats/ Disallow: /servicios/ Disallow: /protegido/ Disallow: /skins/ Disallow: /Eventos/ Disallow: /buscador/ Disallow: /apps/
... Se puede utilizar la directiva Allow para permitir incluir ciertos directorios. En el ejemplo citado se emplea:
Disallow: /protegido/
... Allow: /protegido/buscador/
En la primera lnea se indica con Disallow que no est permitido ingresar al directorio protegido, pero a travs de Allow se indica que se puede registrar el directorio buscador dentro de protegido. Analizar nuestro robots.txt utilizando las Herramientas para webmasters de Google Google proporciona una funcin de Anlisis de robots.txt como parte de sus Herramientas para webmasters de Google, que puede resultar de ayuda para probar si nuestro archivo robots.txt est funcionando segn lo esperado. Instrucciones de uso 18. Acceder a las Herramientas para webmasters de Google http://www.google.com/webmasters/tools/?hl=es (requiere cuenta de Google/Gmail) 19. Aadir su portal y verificar que usted tiene derechos de administracin sobre el mismo, luego podr seleccionar su portal desde el Panel, haciendo clic en la URL del mismo. 20. Hacer clic en Informacin del sitio y seguidamente en Acceso de rastreadores Algunos robots de bsqueda pueden ignorar intencionadamente las directivas Disallow que se especifiquen en el archivo robots.txt, por lo cual no debe tomarse este control como un mecanismo que impone restricciones en cmo el contenido Web deba ser accedido o distribuido. En particular para aquellas secciones restringidas slo a personal autorizado deben implementarse controles de acceso. Visite la pgina http://www.robotstxt.org/faq.html para obtener informacin sobre cmo dirigir el comportamiento de los robots que visiten su portal.
Manejo adecuado de errores

Nuestros portales frecuentemente generan mensajes de error durante su operacin normal. Estos errores deben ser manejados de acuerdo a un esquema bien pensado que provea al usuario de un mensaje con sentido, informacin de
diagnstico para quienes mantienen el sitio, y ninguna informacin til para un atacante. El manejo de errores debe contemplar tanto las entradas generadas por el usuario, as como cualquier error que pueda ser generado por componentes internos como ser: llamadas al sistema, consultas a base de datos o cualquier otra funcin interna. La amenaza de no realizar un correcto manejo de errores radica en revelar informacin detallada a travs del mensaje de error, como el contenido de variables, nombres de directorios e informacin sobre la base de datos, la cual puede ser explotada por un usuario malintencionado para generar un ataque contra nuestro portal.
Ejemplo
Un claro ejemplo de un mal manejo del error sera, presentar, ante un intento fallido de acceso a una seccin reservada de nuestro portal, un mensaje de error especificando qu ha fallado, si ha sido la identificacin (usuario) o la autenticacin (contrasea). Por el contrario la forma correcta sera simplemente notificarle al usuario que hay un error en los datos proporcionados sin otorgar mayor detalle.
Para evitar un manejo inadecuado de los errores se recomienda: Fuente: basado en la proteccin de la vulnerabilidad A6 del OWASP Top Ten 2007 [4]
Exigir al equipo de desarrollo un esquema comn para el tratamiento de errores o bien asegurar que la herramienta de administracin del portal prevea un manejo adecuado de los errores. No mostrar mensajes de error que presenten informacin detallada del mismo. Estandarizar los mensajes de error. Por mayor informacin visite el Captulo de Manejo de Errores de OWASP: http://www.owasp.org/index.php/Error_Handling
Galletas de la fortuna - Usar cookies de forma segura

Las cookies son archivos creados por los sitios Web para almacenar en los equipos de sus visitantes informacin especfica sobre estos. La principal utilidad de las cookies radica en almacenar datos y preferencias de los usuarios a fin de que nuestro portal pueda reconocer un navegador (usuario) especfico.
Dado que las cookies se envan generalmente en texto claro (no cifrado) y se almacena de igual forma en el equipo del usuario, son vulnerables a ataques que comprometen su integridad. Por lo tanto, las cookies que genere nuestro portal no deberan contener datos que pueden ser utilizados directamente por un atacante (por ejemplo, las credenciales de un usuario). Algunas de las operaciones que se pueden realizar mediante el uso de cookies pueden ser suplantadas por otros mecanismos ms seguros, por ejemplo para mantener la informacin de sesin, el identificador de sesin se pueden pasar como parte de la direccin URL del portal en lugar de almacenarse en una cookie. El uso de cookies debera reforzarse con la implementacin de canales seguros (ver seccin Canales seguros de comunicacin) Se recomienda al utilizar cookies en nuestro portal considerar lo siguiente: Evaluar cifrar la informacin almacenada en las cookies; Evitar cookies longevas, limitando su tiempo de vigencia a lo mnimo imprescindible; Evitar almacenar informacin confidencial en una cookie.
Por informacin adicional sobre las precauciones necesarias al asignar cookies puede consultar el apartado 4.5.2 Pruebas para atributos de cookies (OWASPSM-002) del OWASP Testing Project [3]
Control de acceso y comunicacin segura

Hemos visto evolucionar las prestaciones de los portales del Estado, de portales puramente institucionales con informacin esttica hasta portales que ofrecen una importante gama de servicios. Con esta creciente oferta de servicios surgi la necesidad de brindarle a los usuarios y las organizaciones las garantas de que la informacin brindada para la prestacin de dichos servicios no sea accedida por terceros no autorizados. Como respuesta a esta necesidad irrumpen los mecanismos de control de acceso y el establecimiento de canales seguros de comunicacin entre el usuario y nuestro portal.
Pasar, pasar... - Control de acceso

La organizacin debe examinar peridicamente toda la informacin accesible desde su portal para determinar los requisitos de seguridad necesarios. Como se menciona anteriormente muchos portales ofrecen diversos servicios los cuales involucran en su gran mayora informacin sensible, para la cual la organizacin debe determinar los usuarios o grupos de usuarios que deben tener acceso. Este control de acceso se apoya en una gama de tecnologas para autenticar y autorizar a los usuarios con diferentes privilegios de acceso a la informacin. Sin autenticacin de usuarios, las organizaciones no podrn restringir el acceso a informacin especfica, destinada slo a usuarios autorizados. Toda la informacin que reside en un servidor Web pblico ser accesible por cualquiera con acceso a Internet. Para aquella informacin de acceso restringido disponible en el portal, la organizacin deber identificar que mecanismo de autenticacin es el ms adecuado. A continuacin presentamos una lista con mecanismos recomendados: Autenticacin basada en formulario Web; Autenticacin basada en la direccin; Autenticacin HTTP bsica; Autenticacin HTTP digest; Autenticacin del cliente mediante Certificado Digital;
Autenticacin basada en formulario Web

Este mecanismo implica una implementacin en nuestro portal de un formulario Web que recoja las credenciales de un usuario (identificacin y clave) y las coteje contra un sistema de control de usuarios, el cual puede ser una base de datos. Esta implementacin debera complementarse con protocolos seguros de comunicacin (ver seccin canales seguros de comunicacin).
Autenticacin basada en la direccin

El mecanismo ms simple de autenticacin, soportado por la mayora de los servidores Web, est basada en la direccin del usuario. El control de acceso se basa en la direccin IP o el nombre del host del usuario que solicita la
informacin. Aunque es fcil de implementar para pequeos grupos de usuarios, la autenticacin basada en la direccin puede ser difcil de gestionar para los sitios Web que tienen una gran poblacin de usuarios potenciales. Este mecanismos de autenticacin se debe utilizar slo cuando se requiere una seguridad mnima, salvo que se emplee en conjunto con otros mtodos de autenticacin ms fuertes.
Autenticacin HTTP bsica

La autenticacin bsica HTTP utiliza la estructura de directorios del servidor Web. Normalmente, todos los archivos de un mismo directorio cuentan con los mismos privilegios de acceso. El mecanismo se instrumenta a travs de una identificacin de usuario y una clave que le permiten acceder al usuario autenticado a un determinado directorio de archivos. El mtodo y la sintaxis para definir y utilizar este mecanismo depende del servidor Web en el cual este alojado nuestro portal. La debilidad de este mecanismo reside en que la clave del usuario es transferida desde el usuario al servidor Web codificada en lugar de viajar cifrada.
Autenticacin HTTP digest

La autenticacin digest puede verse como una versin mejorada de la autenticacin bsica, ambas incorporadas dentro de la definicin del protocolo HTTP. La diferencia radica en cmo se comunican las credenciales que otorga el usuario. En este caso se codifican los datos del usuario mediante el algoritmo criptogrfico MD5 al cual se aade una marca de tiempo generada por el servidor y la URL solicitada, esta ltima tambin cifrada. Este mecanismo es ms seguro que la autenticacin bsica sin embargo no est soportado por todos los navegadores.
Autenticacin del cliente mediante Certificado Digital

Los protocolos SSL/TLS permiten a un servidor Web confirmar la identidad de un usuario, validando su Certificado Digital y confirmando que el mismo fue emitido por una CA que figuran en la lista de entidades emisoras de certificados de confianza. Este mecanismo debe ser considerado slo en aquellos casos que la informacin que va a ser accedida reviste de una sensibilidad importante. Puede encontrar informacin adicional sobre control de acceso en el captulo 11 de la Norma UNIT-ISO/IEC 27002:2005.
Dime con quin hablas y te dir quin eres Canales seguros de comunicacin
Se debe preservar tambin la confidencialidad y la integridad de la informacin sensible que mencionbamos anteriormente, para ello resulta necesario establecer canales de comunicacin seguros. Se pueden utilizar tcnicas criptogrficas para proteger la informacin que atraviesa la conexin entre un usuario y nuestro portal, en particular se recomienda el empleo de los protocolos SSL y TLS para el cifrado de la comunicacin. Sin el cifrado, cualquier persona con acceso al trfico de la red puede determinar y posiblemente alterar el contenido de la informacin sensible, incluso si el usuario se ha autenticado adecuadamente. Se debe verificar que aquellas pginas o secciones de nuestro portal para las cuales se haya decidido establecer acceso mediante SSL/TLS slo sean accesibles por este mecanismo. La direccin URL de las pginas protegidas mediante SSL o TLS deberan comenzar con https://. Otra manera de identificar una pgina Web protegida por SSL, es a travs de la imagen del "candado" que exhiben la mayora de los navegadores en su parte inferior, tal como se muestra en la figura debajo para el caso del navegador Mozilla Firefox.
Los protocolos mencionados anteriormente, adems de proveer cifrado de la informacin en trnsito, permite la identificacin de los clientes y de los servidores mediante certificados digitales. El caso de la identificacin de los clientes se present en el apartado control de acceso, por otra parte, la identificacin del servidor garantiza a los usuarios que se est ante el portal "autntico" y no una versin falsificada operada por una entidad maliciosa. La identificacin mediante certificados digitales debe, siempre que corresponda, estar alineada a las disposiciones de la Ley N 18.600 sobre Documento Electrnico y Firma Electrnica que regula los servicios de certificacin. La implementacin de los canales seguros reside en el administrador de nuestro servidor Web.
Protegiendo la integridad de su portal

Como comentamos en la seccin anterior dada la creciente oferta de servicios que se brindan desde nuestros portales, los mismos tienden en gran medida a transformarse en aplicaciones Web con complejas implementaciones de funciones de software. Quizs una de las principales amenazas que enfrentan en la actualidad los portales Web es la explotacin de vulnerabilidades en dichas aplicaciones Web y la forma en que la informacin se procesa en los servidores Web. Estos ataques explotan los elementos interactivos de nuestros portales Web.
Ms vale malo conocido... - Validacin de los datos de entrada

En aquellos casos que contemos con elementos interactivos en nuestros portales Web y siempre que estos requieran ingreso de datos por parte de los usuarios, como por ejemplo formularios de contacto, debemos adoptar como regla general, nunca dar por sentado que estas entradas son confiables. Si nuestro portal no tiene establecido un mecanismo adecuado para restringir la entrada de datos, un atacante podra entrar cierto tipo de informacin afectando negativamente nuestro portal y comprometiendo su seguridad. La ausencia de controles que validen las entradas de los usuarios constituye una de las mayores debilidades de los portales interactivos. Esta debilidad conduce a las principales amenazas en aplicaciones Web, como por ejemplo, inyeccin SQL o Cross Site Scripting (XSS). A fin de protegerse de entradas de datos malintencionadas, se recomienda que su portal contemple las siguientes indicaciones: Para los formularios de entrada de datos, determinar una lista de caracteres posibles y filtrar los caracteres inesperados de los datos de entrada introducidos por un usuario antes de procesar un formulario. Por ejemplo, en la mayora de los formularios se esperan como datos de entrada, letras de la a a la z(minsculas o maysculas) y nmeros del 0 al 9. Si debemos desplegar en pantalla una entrada del usuario, por ejemplo para confirmar sus datos, debemos previamente filtrar dicha entrada. En particular en el caso de admitir elementos HTML estos deben ser codificados. Por ejemplo, a fin de evitar una ventana emergente con el texto Soy pasible de un ataque de XSS deberamos convertir la
entrada del usuario <script>alert(Soy pasible de un ataque de XSS);</script> en lt;script>alert(Soy pasible de un ataque de XSS);</script>. De esta manera convertimos cualquier secuencia de comandos potencialmente peligrosa en cadenas visibles, pero no ejecutables. No almacene nunca informacin proporcionada por el usuario sin filtrar en una base de datos. Tenga en cuenta que la informacin que el navegador enva al servidor puede ser suplantada, por tanto desconfe de todo parmetro de entrada, incluyendo URLs, cadenas de consulta, encabezados HTTP, cookies o campos de formularios.
Se describen a continuacin algunas de las principales amenazas relacionadas con la falta de validacin de datos de entrada.
Inyeccin SQL
En este tipo de ataque, una entidad maliciosa enva a travs de una entrada un comando o cadena SQL especfica a la base de datos de nuestro portal, que al no pasar por la validacin correspondiente, podra llegar a devolver al atacante cualquier informacin almacenada en dicha base de datos. Las fallas de inyeccin SQL, tambin permiten al atacante crear, modificar o borrar cualquier informacin arbitraria disponible en la base de datos de nuestro portal. Por informacin detallada sobre fallas de inyeccin y mecanismos de proteccin consulte la vulnerabilidad A2 del OWASP Top Ten 2007 [4].
Secuencia de comandos en Sitios Cruzados [del ingls Cross Site Scripting] (XSS)
La secuencia de comandos en sitios cruzados, ms conocida como XSS, es una amenaza que afecta aplicaciones Web interactivas que permite inyeccin de cdigo malicioso de usuarios de Internet en las pginas Web visitadas por otros usuarios. XSS permite a los atacantes ejecutar secuencias de comandos que pueden secuestrar sesiones de usuario, modificar sitios Web, insertar contenido hostil, realizar ataques de phising y tomar control del navegador Web del usuario. Por mayor informacin sobre Cross Site Scripting y mecanismos de proteccin consulte la vulnerabilidad A1 del OWASP Top Ten 2007 [4]
Destino incierto Redireccin de dominios (Pharming)

La amenaza de redireccin de dominio aparece ante las vulnerabilidades de los sistemas de administracin y asignacin de nombres de dominio (DNS)18, los cuales se utilizan para asociar nombres en lenguaje natural a las direcciones IP de nuestros servidores Web, o mediante la alteracin de los archivos host del equipo del cliente que utiliza para resolver localmente (asociar IP a lenguaje natural) los nombres de dominio de Internet. En cualquier caso, el sistema afectado va a dirigir nombres legtimos de nuestros portales Web a direcciones de sitios Web malintencionados. A continuacin se describen algunas prcticas para evitar la redireccin de dominios:
Fuente: basado en las tcnicas anti-Pharming presentadas en el apartado 6.3.2 de la Norma NIST SP 800-44 [2]
Asegurar la utilizacin de la versin vigente del software DNS con los ltimos parches de seguridad aplicados. Instalar mecanismos de proteccin contra pharming en el servidor DNS. Monitorear los dominios de la organizacin y el registro de dominios similares. En el caso de existencia de nombres de dominio similares los atacantes podran tomar ventaja de los errores de los usuarios al digitar la direccin. Simplificar la estructura y el nmero de nombres de dominio de nuestra organizacin. Si una organizacin tiene una estructura de nombres complicados para sus servidores, se hace cada vez ms difcil para los usuarios discernir si estn en un sitio ilegtimo. Usar canales seguros de comunicacin para inicios de sesin, que permitan a los usuarios verificar que los certificados del servidor son vlidos y estn asociados con un sitio Web legtimo.
18
En el captulo Normativa a cumplir se profundiza sobre Nombres de dominios
Protegerse contra amenazas de negacin de servicio

Los ataques de negacin de servicios buscan deshabilitar un servicio o dejar completamente fuera de lnea un portal. La idea tras estos ataques radica en saturar un equipo, aplicacin, servicio o canal de comunicacin, de forma tal que se impide la prestacin de los servicios e incluso la cada del equipo que alberga nuestro portal por tiempo indeterminado. Este tipo de ataque generalmente va ms all de lo que se puede evitar en la implementacin de nuestro portal. Sin embargo existen tipos de vulnerabilidades dentro de las aplicaciones Web que permiten a un usuario malicioso provocar que algunas funcionalidades o en ocasiones el portal en su conjunto queden no disponibles. Estos problemas son causados por errores en la aplicacin, a menudo como resultado de entradas maliciosas o valores de entrada no esperados. Se presentan a continuacin algunas pautas para prevenir ataques de negacin de servicios.
Limitar consultas a bases de datos

En caso de portales interactivos con manejo de base de datos, se recomienda limitar las consultas a la base de datos para protegerse frente a consultas grandes que consuman los recursos del sistema. Un ejemplo de consultas maliciosas lo constituye el uso de comodines en los formularios de bsqueda de nuestros portales. Consultas que incluyan caracteres como "[]","[^]","_" y "%", interpretados por la mayora de los motores de base de datos como comodines, pueden requerir un uso intensivo del procesador. Algunas de las tcnicas que se pueden implementar para limitar las consultas a bases de datos son: Contar con un listado de caracteres aceptados (ver apartado Validacin de los datos de entrada); Implementar CAPTCHA19 en formularios de bsqueda avanzada20;
19
http://es.wikipedia.org/wiki/Captcha Las tcnicas de CAPTCHA implementadas deben cubrir los requisitos de accesibilidad (ver captulo Accesibilidad)
20
Iimitar el tiempo de ejecucin de las consultas SQL; Limitar el nmero de registros devueltos por una consulta a la base de datos;
Evitar bloqueos de cuentas de usuarios de forma malintencionada

Una defensa comnmente usada para evitar el descubrimiento de contraseas de usuarios por fuerza bruta es bloquear el uso de una cuenta despus de varios intentos fallidos de autenticacin. Eso significa que incluso si un usuario legtimo proporcionase su contrasea vlida, no podra registrarse en el sistema hasta que su cuenta haya sido desbloqueada. Este mecanismo de defensa puede convertirse en un ataque de negacin de servicio contra nuestro portal Web si el atacante conoce o puede deducir nombres de cuentas vlidos. En caso de contar con secciones que requieran autenticacin y se utilice este mecanismo de bloque de cuentas, es necesario asegurar que un atacante no podr recolectar identificadores de usuarios vlidos, con los cuales lanzar un ataque de negacin de servicios. Tener presente que para evitar esto es preciso: Realizar un adecuado manejo de los errores presentados al usuario ante intentos fallidos de autenticacin, evitando divulgar cualquier informacin que pueda servir para identificar cuentas vlidas. Si el portal permite crear cuentas nuevas eligiendo el nombre de usuario, los controles de redundancia de usuarios revelarn la existencia de cuentas vlidas. En los casos que el portal prevea el reinicio de claves, asegurar los mensajes desplegados para cuentas inexistentes.
Evitar desbordamientos de buffer

Un desbordamiento de buffer es un error de software causado por un defecto de programacin que se produce cuando se copia una cantidad de datos sobre un rea que no es lo suficientemente grande para contenerlos, sobrescribiendo de esta manera otras zonas de memoria. Si se produce la escritura fuera de una zona de memoria protegida esto dar lugar a la terminacin del programa. Esto puede afectar nuestros portales interactivos, produciendo la no disponibilidad de los servicios. Para evitar ataques de este tipo se recomienda:
Validar los datos de entrada (ver seccin correspondiente); Verificar que los servidores Web, de aplicaciones y de bases de datos se encuentren con las ltimas actualizaciones tanto a nivel de sistema operativo como en las aplicaciones de seguridad(antivirus, malware, etc.).
Limitar la escritura a disco

Un atacante podra afectar la disponibilidad de nuestro portal valindose de la inexistencia de lmites en la carga de archivos o almacenaje de datos de registro. Una vez ms este tipo de ataque afecta slo aquellos portales con caractersticas interactivas. Para evitar el llenado de los discos de forma maliciosa, se recomienda: Comprobar los lmites de tamao de la entrada del usuario antes de usarla o almacenarla. Si se le permite al usuario cargar archivos establecer un lmite de tamao para los mismos.
Resguardo de la informacin
Con el fin de mantener la integridad y disponibilidad de nuestro portal resulta necesario realizar regularmente copias de seguridad del software y la informacin que lo constituyen. Los respaldos deberan garantizar que toda la informacin esencial y el software puedan recuperarse tras un acto malicioso o accidental o de un error de hardware o software. Deberan considerarse los siguientes elementos para el respaldo de la informacin y el software de nuestro portal:
Fuente: basado en la Gua de implementacin presentada en el apartado 10.5.1 de la Norma UNIT-ISO/IEC 27002:2005 [1]
El grado (por ejemplo, respaldo completo o diferencial) y la frecuencia de los respaldos deberan reflejar los requisitos del negocio y los requisitos de seguridad de la informacin implicada;
Los respaldos deberan almacenarse en un lugar apartado, a una distancia adecuada que garantice que cualquier dao en el sitio principal no los afecte; La informacin de respaldo debera tener un nivel apropiado de proteccin ambiental y fsico consistente con las normas aplicadas en el sitio principal; Los controles aplicados a los soportes en el sitio principal se deben ampliar para cubrir el sitio de respaldo; Debera probarse peridicamente la correcta restauracin de las copias de seguridad; En caso de informacin confidencial, los respaldos deberan protegerse por medio del cifrado.
Monitoreo
El registro de las actividades en nuestro portal es vital para detectar acciones no autorizadas y fallas en el mismo. Es importante recoger los datos correctos en los registros de auditora (logs) y dar seguimiento a los mismos. A la hora de identificar que registros mantener deberan considerarse los logs del servidor Web y evaluar la necesidad de que las aplicaciones Web (implementaciones de servicios) mantengan sus propios registros de las acciones. Por ejemplo una seccin restringida debera incluir en sus registros de auditora, cuando sea relevante: Identificacin del usuario que accede; Fechas, horas, y los detalles de acontecimientos claves, por ejemplo inicio y fin de una sesin; Identidad del equipo y ubicacin, si es posible; Registros de los intentos aceptados y rechazados de acceso a la seccin; Archivos accedidos y la clase de acceso;
Muchas veces la revisin de logs es trivial y reactiva, la misma es considerada mayoritariamente como tediosa, sin embargo, es importante sealar que los logs a menudo son el nico registro de un comportamiento sospechoso. Es recomendable valerse de procedimientos y herramientas para procesar y analizar los logs y revisar las notificaciones de alerta.
Los registros de auditora pueden contener datos personales confidenciales e indiscretos. Deberan tomarse medidas de proteccin de privacidad. De ser posible, los administradores de sistema no deberan tener el permiso de borrar o desactivar los registros de sus propias actividades.
Lista de Verificacin de Seguridad de un Portal
Accin Generar el archivo robots.txt En caso de producirse errores se despliegan mensajes adecuados que no brindan informacin detallada del mismo Prohibir el uso de cookies persistentes Usar la cookie de sesin slo si est claramente identificada en la poltica de privacidad No se almacena en las cookies informacin confidencial en claro Para los recursos del portal que requieren una proteccin mnima y para los cuales hay una pequea y claramente definida audiencia, se ha configurado Autenticacin basada en la direccin Para los recursos del portal que requieren proteccin adicional y para los cuales hay una pequea y claramente definida audiencia, se ha configurado Autenticacin basada en la direccin como segunda lnea de defensa complementada con Autenticacin basada en formulario Web Para los recursos del portal que requieren una proteccin mnima pero no tienen definido una audiencia clara, se ha configurado Autenticacin HTTP bsica o digest (mejor opcin) Para los recursos del portal que requieren proteccin adicional pero no tienen definido una audiencia clara, se ha configurado Autenticacin basada en formulario Web y Autenticacin HTTP bsica o digest (mejor opcin) como segunda lnea de defensa Para los recursos del portal que requieren mxima proteccin, se ha configurado SSL / TLS
Completada
Accin Para las configuraciones que requieran un nivel de seguridad medio en la autenticacin de clientes, se ha configurado el servidor para exigir el nombre de usuario y la contrasea a travs de SSL/TLS Para las configuraciones que requieren un nivel de seguridad alto en la autenticacin de clientes, se ha configurado el servidor para requerir certificados digital de cliente a travs de SSL/TLS En los casos que se autentique mediante certificados digitales se ha verificado la alineacin con las disposiciones de la Ley N 18.600 Toda entrada de usuario es validada Se ha personalizado el contenido Web para ayudar a los usuarios ha identificar los sitios Web fraudulentos Se utilizan las versiones actuales del software DNS con los ltimos parches de seguridad Se han Instalado del lado del servidor mecanismos de proteccin de DNS Se realiza el seguimiento de los dominios de la organizacin y dominios similares Se ha simplificado la estructura de nombres de dominio de la organizacin Las consultas a bases de datos que requieren entradas de usuarios cuentan con listas de caracteres aceptados En aquellos casos que sea factible, se han implementado tcnicas CAPTCHA en los formularios de bsqueda avanzada Se han establecido lmites temporales a la ejecucin de consultas SQL Se ha limitado el nmero de registros devueltos por una consulta a nuestra base de datos Se han asegurados las cuentas de usuarios
Completada
Accin Se ha verificado que los servidores Web, de aplicaciones y de bases de datos se encuentren con las ltimas actualizaciones tanto a nivel de sistema operativo como en las aplicaciones de seguridad (antivirus, malware, etc.) Se verifican los tamaos de las entradas de usuario antes de almacenarlas en disco Se ha establecido una sistemtica de respaldo peridica para el software y la informacin del portal Se ha verificado la recuperacin exitosa de los respaldos del software y la informacin del portal Los respaldos del portal se almacenan en un lugar apartado del sitio principal Se cifran los respaldos de la informacin confidencial del portal Se mantienen los registros de auditora (logs) adecuados a los requisitos de la organizacin Se revisan peridicamente los logs Se protegen adecuadamente los logs contra modificaciones
Completada
Captulo VI
Glosario de trminos y referencias
Captulo VI Glosario y Referencias | 283
Glosario de trminos
Definicin de todos los trminos, siglas y abreviaturas necesarios para interpretar apropiadamente esta gua. CSS Cascading Style Sheets (Hojas de Estilo en Cascada). Es un lenguaje utilizado para definir la presentacin de un documento estructurado en HTML o XML (por extensin (X)HTML. El W3C es el encargado de formular la especificacin de las Hojas de Estilo en Cascada. DTD Document Type Definition (Definicin de Tipo de Documento). Es una descripcin de estructura y sintaxis de un documento XML o SGML. HTML HyperText Markup Language (Lenguaje de Marcas de Hipertexto). Es el lenguaje de marcado predominante para la construccin de pginas Web. Este lenguaje es utilizado para describir la estructura y el contenido en forma de texto, as para complementar dicho texto con objetos tipo imgenes. ISO International Organization for Standardization (Organizacin Internacional para la Estandarizacin). ISO es el organismo encargado de promover el desarrollo de normas internacionales para todas las ramas industriales, excepto de la elctrica y la electrnica. MathML Mathematical Markup Language (Lenguaje de Marcado para Expresiones Matemticas). Es un lenguaje de marcado basado en XML, cuyo objetivo es expresar notaciones matemticas de forma que distintas maquinas puedan entenderla. SGML Standard Generalized Markup Language (Lenguaje de Marcado Generalizado). Es un lenguaje que ayuda en la organizacin y etiquetado de documentos. La ISO (Organizacin Internacional de Estndares) normalizo este lenguaje en 1986. SMIL Synchronized Multimedia Integration Language (Lenguaje de Integracin Multimedia Sincronizada). Es un lenguaje estndar del W3C (World Wide Web Consortium) para presentaciones multimedia, que permite integrar imgenes, audio, video, texto u otro tipo de objeto multimedia. SVG Scalable Vector Graphics. Es una especificacin para describir grficos vectoriales bidimensionales, tanto estticos como animados (estos ltimos con ayuda de SMIL), en formato XML.
URL Uniform Resource Locator (Localizador de Recurso Uniforme). Direccin global de documentos y de otros recursos en la WWW (World Wide Web). W3C World Wide Web Consortium (Consorcio World Wide Web). Es un consorcio internacional el cual trabaja en el desarrollo de protocolos y estndares Web. XML Extensible Markup Language (Lenguaje de Marcado Extensible). Es un conjunto de normas para la codificacin de documentos electrnicos. CA (por sus siglas en ingls Certificate Authority) Entidad de confianza, responsable de emitir y revocar los certificados digitales. Certificado Digital Un certificado digital es un documento digital mediante el cual un tercero confiable (una autoridad de certificacin) garantiza la vinculacin entre la identidad de un sujeto o entidad y su clave pblica. HTTP (por sus siglas en ingls HyperText Transfer Protocol) Protocolo de transferencia de hipertexto. Es el protocolo usado en cada transaccin de la Web. MD5 En criptografa, MD5 (abreviatura de Message-Digest Algorithm 5, Algoritmo de Resumen del Mensaje 5) es un algoritmo de reduccin criptogrfico de 128 bits ampliamente usado. Phising modalidad de ataque que utiliza tcnicas de ingeniera social para engaar a los usuarios logrando que accedan a un sitio Web falso y divulguen informacin personal. SQL (por sus siglas en ingls Structured Query Language) El lenguaje de consulta estructurado SQL es un lenguaje declarativo de acceso a bases de datos relacionales que permite efectuar consultas con el fin de recuperar informacin de inters de una base de datos, as como tambin hacer cambios sobre ella. SSL (por sus siglas en ingls Secure Sockets Layer) Protocolo criptogrfico que proporciona comunicaciones seguras por una red, comnmente Internet. TLS (por sus siglas en ingls Transport Layer Security) Protocolo criptogrfico establecido como el sucesor del protocolo SSL.
URL (por sus siglas en ingls Uniform Resource Locator) Secuencia de caracteres, de acuerdo a un formato estndar, que se usa para nombrar recursos de informacin disponibles en Internet.
Referencias
Este captulo ha sido desarrollado, tomando en cuenta recomendaciones de las siguientes fuentes, las que adems contienen material de utilidad para profundizar en diferentes temas. Gua para el Desarrollo de Sitios Web de Chile Versin 2.0 http://www.guiaweb.gob.cl/guia/capitulos/tres/experiencia.htm
Gua para el desarrollo de Sitios web de la Administracin Pblica de Mxico http://www.sip.gob.mx/recursos-guia-desarrollo
Observatorio de usabilidad http://www.observatoriodeusabilidad.cl/?p=105
Gua de CSS W3C http://www.w3.org/ http://www.w3c.es/divulgacion/guiasbreves/HojasEstilo
W3C Espaa http://www.w3c.es/
W3C - WAI http://w3c.es/Traducciones/es/WAI/intro/accessibility
Blog de Olga Carreras Usable y Accesible http://olgacarreras.blogspot.com/
Artculo sobre la optimizacin de los tiempos de carga (ingls): http://www.die.net/musings/page_load_time/
INTECO http://www.inteco.es/Accesibilidad/
Puntos de verificacin de Qweos http://qweos.net/blog/2009/01/28/guias-practicas-para-profesionalesWeb-puntos-de-verificacion-de-las-pautas-de-accesibilidad-alcontenido-Web-wcag-20/comment-page-1/#perceptible
Wikipedia http://es.wikipedia.org/wiki/Accesibilidad_Web
AENOR Normativa UNE 139803:2004 UNIT-ISO/IEC 27002:2005 NIST Special Publication 800-44 Version 2 OWASP Testing Project http://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_O WASP_ver_3.0.pdf [4] OWASP Top Ten 2007https://www.owasp.org/images/a/ae/OWASP_Top_10_2007_Spanish.p df
Seguridad en Sitios Web Producido por ArCERT Versin 1.1
Tabla de contenidos
Planificar y desarrollar un portal .............................................................................................................. 7 Comenzando a trabajar ......................................................................................................................... 10
Equipo de direccin de proyecto ....................................................................................................................... 11
Relevamiento ......................................................................................................................................... 17
Relevamiento de contenidos ............................................................................................................................. 17 Seleccin de las herramientas y opciones para la implementacin ................................................................... 25 Plan de contenidos ............................................................................................................................................ 25 Diseo del Portal ............................................................................................................................................... 29 Maquetacin e implementacin ......................................................................................................................... 34 Validacin y Puesta en produccin .................................................................................................................... 35 Gestin de los contenidos ................................................................................................................................. 38 Lista de revisin ................................................................................................................................................. 41 Formulario de relevamiento ............................................................................................................................... 44
Qu es la Usabilidad ............................................................................................................................. 49
La mejor interfaz es la que no existe ................................................................................................................. 50 Beneficios .......................................................................................................................................................... 51
Elementos de la interfaz de usuario ...................................................................................................... 53

Objetivos............................................................................................................................................................ 54 Alcance .............................................................................................................................................................. 55 Arquitectura de la informacin ........................................................................................................................... 64 Modelo de Interaccin ....................................................................................................................................... 66 Interfaz............................................................................................................................................................... 71
Miro, leo, pienso: tres niveles de interaccin ........................................................................................ 75

Tres niveles de interaccin ................................................................................................................................ 75 Miro y entiendo .................................................................................................................................................. 75 Leo y entiendo ................................................................................................................................................... 77 Pienso y entiendo .............................................................................................................................................. 78 Estructura y contenido ....................................................................................................................................... 78
Mtodos de evaluacin de Usabilidad .................................................................................................. 82

Anlisis Heurstico ............................................................................................................................................. 82 Test con Usuarios.............................................................................................................................................. 91
Redactar para la Web ........................................................................................................................... 94

Cada medio tiene su lenguaje ........................................................................................................................... 94 Cmo leen los internautas ................................................................................................................................. 94 Estilos de escritura ............................................................................................................................................ 97 Tcnicas de escritura para la Web .................................................................................................................... 97 Organizando el contenido................................................................................................................................ 100 Ni magia ni dogmas ......................................................................................................................................... 101
Formularios: la Web interactiva ........................................................................................................... 103

Usabilidad de los formularios .......................................................................................................................... 103 Los campos y sus etiquetas ............................................................................................................................ 106 Manejo de errores y mensajes ........................................................................................................................ 109 Recomendaciones particulares para elaborar buenos formularios .................................................................. 111
Accesibilidad Web ............................................................................................................................... 121

Acceso sin barreraspor Humberto Demarco ............................................................................................. 121 Introduccin ..................................................................................................................................................... 123 Accesibilidad en los portales del Estado ......................................................................................................... 125
Cmo lograr que el sitio Web sea accesible ....................................................................................... 127

Criterios de Accesibilidad para los portales de Gobierno ................................................................................ 129 Pautas ............................................................................................................................................................. 130
Comprobacin de la Accesibilidad Web.............................................................................................. 153

Evaluacin y Comprobacin Automtica ......................................................................................................... 154 Validacin de la Accesibilidad ......................................................................................................................... 168
Recomendaciones tcnicas para desarrolladores .............................................................................. 188

1. Perceptibilidad ........................................................................................................................................ 188
Adaptabilidad................................................................................................................................................... 196 Distinguible ...................................................................................................................................................... 201 Operabilidad .................................................................................................................................................... 203
Navegable ....................................................................................................................................................... 210 Comprensible .................................................................................................................................................. 214 Predecible ........................................................................................................................................................ 215 Ayuda a la entrada de datos ............................................................................................................................ 217 Robustez ......................................................................................................................................................... 219
Anexo estructura del HTML y CSS...................................................................................................... 221

C22: Usar CSS para controlar la presentacin visual del texto ....................................................................... 221
Anexo otras tecnologas ...................................................................................................................... 223

Contenidos Flash ............................................................................................................................................. 223 Contenidos pdf ................................................................................................................................................ 223 Contenidos de documentos de texto ............................................................................................................... 223 Ejemplo 1 de Poltica de Accesibilidad para incluir en el Portal ....................................................................... 225 Ejemplo 2 Uso de los smbolos y sellos de cumplimiento ................................................................................ 226
Aspectos normativos ........................................................................................................................... 229 Proteccin de la propiedad intelectual ................................................................................................ 230

Qu es la propiedad intelectual? ................................................................................................................... 230 Cmo respetar estos derechos?.................................................................................................................... 231 Recomendaciones ........................................................................................................................................... 232 Cmo implementar las recomendaciones? ................................................................................................... 234
Transparencia ...................................................................................................................................... 240

Cmo garantizar la transparencia de la funcin pblica? .............................................................................. 241
Privacidad ............................................................................................................................................ 249

Principales conceptos ...................................................................................................................................... 251 Recomendaciones ........................................................................................................................................... 253 Cmo implementar las recomendaciones? ................................................................................................... 254
Nombres de dominio ........................................................................................................................... 256

Qu son y cmo se registran? ....................................................................................................................... 256
Avisos Legales .................................................................................................................................... 257 Seguridad del Portal ............................................................................................................................ 261

Proteccin contra divulgacin de informacin no autorizada ........................................................................... 261
Control de acceso y comunicacin segura ...................................................................................................... 266 Protegiendo la integridad de su portal ............................................................................................................. 270 Protegerse contra amenazas de negacin de servicio .................................................................................... 273 Resguardo de la informacin ........................................................................................................................... 275 Monitoreo ........................................................................................................................................................ 276 Lista de Verificacin de Seguridad de un Portal .............................................................................................. 278
Glosario de trminos ........................................................................................................................... 283 Referencias ......................................................................................................................................... 286 Tabla de contenidos ............................................................................................................................ 288

Guia Completa Doble Faz

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia Completa Doble Faz

Uploaded by

Copyright:

Available Formats

GUIAS PARA DISEO E IMPLEMENTACION DE

BUENAS PRCTICAS Versin 1.0 2009

Mejoremos el acceso al Estado a travs de un mejor desarrollo de la Web

Planificar y Desarrollar un portal

Captulo I Desarrollar un portal | 7

Planificar y desarrollar un portal

8 | Captulo I Desarrollar un portal

Ejemplo de plan de actividades

Captulo I Desarrollar un portal | 9

10 | Captulo I Desarrollar un portal

Fuente: Curso de Estrategias de Gobierno Electrnico OEA

Captulo I Desarrollar un portal | 11

Equipo de direccin de proyecto

Estrategia del sitio

12 | Captulo I Desarrollar un portal

Nivel de desarrollo del portal del organismo

De inters del usuario Informacin

Usuario Institucin Usuario Usuario

Fuente: Curso de Introduccin a la elaboracin de Estrategias de Gobierno Electrnico de la OEA

Captulo I Desarrollar un portal | 13

14 | Captulo I Desarrollar un portal

Informacin y productos a difundir

Captulo I Desarrollar un portal | 15

Primera composicin del portal

16 | Captulo I Desarrollar un portal

tomadores de decisiones que deben estar informados de la

estrategias de gobierno electrnico y de los lineamientos para los proyectos,

proyectos tecnolgicos y encontrar oportunidades de negocios

Captulo I Desarrollar un portal | 17

18 | Captulo I Desarrollar un portal

Captulo I Desarrollar un portal | 19

Especificacin de los requerimientos funcionalidades

20 | Captulo I Desarrollar un portal

Ruta de Acceso o camino de migas

Mapa del sitio:

Manejo de histricos de publicaciones, documentos, noticias:

Captulo I Desarrollar un portal | 21

22 | Captulo I Desarrollar un portal

Funcionalidades de administracin y diseo

Administracin de plantillas y estilos

Log de auditora del portal:

Captulo I Desarrollar un portal | 23

Requerimientos de usuarios y roles

24 | Captulo I Desarrollar un portal

Normativa que debe cumplir

Captulo I Desarrollar un portal | 25

Seleccin de las herramientas y opciones para la implementacin

26 | Captulo I Desarrollar un portal

En Internet dispone de bancos de imgenes libres que puede utilizar:

Captulo I Desarrollar un portal | 27

28 | Captulo I Desarrollar un portal

Captulo I Desarrollar un portal | 29

Diseo del Portal

30 | Captulo I Desarrollar un portal

Captulo I Desarrollar un portal | 31

32 | Captulo I Desarrollar un portal

A continuacin se muestra el boceto con la esttica incluida.

Captulo I Desarrollar un portal | 33

34 | Captulo I Desarrollar un portal

Captulo I Desarrollar un portal | 35

Validacin y Puesta en produccin

36 | Captulo I Desarrollar un portal

Captulo I Desarrollar un portal | 37

38 | Captulo I Desarrollar un portal