Qué cosas podemos hacer desde el diseño y las funcionalidades de un sitio para provocar que los usuarios actúen?

1)     Mostrar lo que hacen otros.

La autora sostiene que los seres humanos, a partir de la búsqueda de la validación social, tienden a comportarse de forma similar y esto se potencia en situaciones de incertidumbre.

¿Cómo podemos utilizar esto para aumentar las ventas en nuestros sitios?

• Incluyendo comentarios de otros usuarios sobre productos comprados.
• Incorporando calificaciones.
• Mostrando las acciones que otros usuarios acaban de realizar.

2) Generar reciprocidad.

Nosotros devolvemos favores y regalos. Esto se llama reciprocidad. Si una persona recibe favores y utilidades de un sitio, se sentirá de algún modo en deuda y “obligado” a devolver el favor.

¿Cómo se puede utilizar la reciprocidad en un sitio?

• Ofreciendo información gratuita. Por ejemplo, en un sitio de venta de cámaras de fotografía, si se incluyera una guía de cómo sacar buenas fotos, esto ayudaría a que el usuario, al momento de realizar una compra, escoja su sitio.
• Mostrando recomendaciones de otros usuarios. Siempre que la información sea útil, será vista como un obsequio.
• Brindando más alternativas para obtener información. Esto también puede ser visto como un regalo.

3) Apelar a la escasez.

“If something is scare, it will seem more desirable and more valuable to us”. (Si algo es escaso, se hace más deseable y más valioso para nosotros). La escasez motiva a las personas a actuar, por miedo a que después sea demasiado tarde.

Lo podemos aplicar de las siguientes formas:

• Limitando promociones por cupos o por tiempo.
• Restringiendo el acceso a cierta información: “Beneficios exclusivos para socios”.

4) Mostrar pocas opciones, elegidas cuidadosamente.

“Given too many choices, we freeze and then we don´t choose at all”. (Ante demasiadas opciones, nos congelamos y no elegimos nada). Decimos que queremos ver muchas opciones, pero la realidad es que ante muchas opciones es más complicado decidir. Por lo tanto, menos es más.

5) Ordenar los productos estratégicamente.

• Efecto orden: En una lista de productos similares, las personas tienden a seleccionar el que está primero.
• Efecto UP-SELL: Los productos nos parecen caros o baratos en función de la última compra que acabamos de hacer.
  Por ejemplo: comprar una alfombra luego de un juego completo de muebles, nos parecerá baratísimo. Por eso, nos conviene ofrecerla como cierre de la compra anterior.

6) Incluir imágenes sensuales o de comida:

La autora sostiene que no hay que permitir que el usuario se aburra y para eso es necesario activar sus partes más primitivas desde la sensualidad y la comida (donde la temática lo permita, claro!).

7) Generar cambios visuales:

El hombre primitivamente, por necesidad de supervivencia, presta atención cuando algo se mueve.

¿Cómo podemos utilizar este instinto humano a favor de nuestros proyectos?

• Incluyendo banners (con precaución!).
• Embebiendo videos.
• Generando cambios visuales entre las distintas pantallas.

8) Todo es sobre “vos”.

“All you need is you”. (Todo lo que necesitás sos vos). La autora propone sacar provecho del egocentrismo del ser humano y utilizar esto para llamar su atención.

¿Cómo aplicarlo?

• Llamando al usuario en segunda persona: “usted, vos, tú”.

9) Hacer que la gente se comprometa escribiendo.

Hacer que la gente escriba, opine o participe fortalece el compromiso de los usuarios con el sitio.

10) Utilizar imágenes e historias.

“If you want to get and hold someone´s attention, tell a story”. Si quieres que alguien preste atención, cuéntale una historia.

Las imágenes combinadas con historias:

• Facilitan la comprensión.
• Captan la atención.
• Ayudan a la memorización.
• Inducen a la acción.

11) Fomentar la socialización.

Somos seres sociales y tendemos a utilizar la tecnología para comunicarnos. Ofrezcamos la posibilidad de imprimir o enviar información, ya sea por mail o a través de las redes sociales. Permitamos recomendar un producto.

El objetivo era verificar que sus sitios fueran comprensibles, perceptibles, operables y compatibles y que estuvieran pensados y diseñados en función de las tareas que los usuarios debían efectuar.

El inconveniente surgió cuando algunos proveedores comenzaron a negarse a hacer modificaciones, dado que estas exigencias no formaban parte de los requerimientos de las licitaciones.

De este modo, surgió la idea de desarrollar una normativa que los instara a hacerlo. Para esto, tuve el privilegio de ser corregida y aconsejada por Martín Baldassarre, Enrique Stanziola, Juan Lanús, Santiago Bustelo, Eduardo Mercovich, Gonzalo Auza, Guillermo Ermel, Celeste Oliveri,  José Allona, Juan Manuel Carraro y Mariano Goren, quien generó rápidamente un encuentro a través de IXDA para sumar aportes.

También se contactaron conmigo Mario Carvajal y Juan Saab Vanegas de Colombia, para enviarme como referencia la leyes de su país.

La normativa fue aprobada por el Secretario de Comunicación Social Gregorio Centurión y se estableció dentro de la Resolución 76/SCS/10 que fue publicada en el boletín oficial del GCBA el día 04/05/2010. La misma hace referencia al texto detallado debajo,  que ya se encuentra en la Intranet de la Agencia de Sistemas de Información del GCBA, disponible para los proveedores:

Normativa de Accesibilidad y Usabilidad Web

1. Ámbito de Aplicación.

Las disposiciones a las cuales se refiere la presente resolución, son de obligatorio cumplimiento para todos los sitios web pertenecientes al Gobierno de la Ciudad Autónoma de Buenos Aires.

2. Objetivos:

Los objetivos de la presente resolución son:

2.1. Garantizar un acceso equitativo a la información.

2.2. Contribuir con la construcción de un Gobierno que preste mejores servicios a los ciudadanos, facilitando a los usuarios el alcancen a sus objetivos con eficacia y satisfacción a través de la optimización de las tecnologías de información y comunicación.

3. Definiciones de usabilidad y accesibilidad web:

Un sitio web es accesible cuando sus contenidos son perceptibles, comprensibles y operables para todo tipo de usuarios, independientemente de sus capacidades, tipo y dispositivo de acceso a internet, sistema operativo y/o programas utilizados

La usabilidad es una medida empírica que califica que tan fácil, rápido y agradable es un sitio web para un cierto tipo de usuario, con determinado tareas y contexto de uso.

4. Definición de políticas y estándares de accesibilidad:

El Consorcio W3, organismo internacional encargado de crear y supervisar los estándares en la Web, ha publicado una serie de pautas denominadas Directrices¹ de Accesibilidad del Contenido Web 2.0. (Versión en inglés Web Content Accessibility Guidelines WCAG – 2.0: http://www.w3.org/TR/WCAG20/#guidelines. Traducción recomendada (aunque no oficial) en español: http://www.sidar.org/traducciones/wcag20/es/), las cuales son aceptadas internacionalmente.

Las Pautas se organizan en cuatro principios básicos que constituyen su base filosófica (perceptible, operable, comprensible y compatible). Las mismas se encuentran clasificadas por niveles de conformidad (A, AA, AAA).

Las aplicaciones y sitios web pertenecientes a los organismos mencionados, creados a partir de abril de 2010 deberán alcanzar el nivel de conformidad AA, aunque se sugiere a los responsables, que traten de llegar al nivel de conformidad AAA.

Las aplicaciones que ya se encuentran en vigencia deberán adoptar dichas pautas a lo largo de un período de dos años a partir del momento en que la presente resolución entre en vigencia.

Para verificar este aspecto se deberán utilizar como referencia las herramientas de validación descriptas en la de Guía de Usabilidad y Accesibilidad Web detallada debajo.

5. Adopción de una Guía de Usabilidad y Accesibilidad Web:

El Área de Usabilidad y Accesibilidad Web creará una Guía para los desarrolladores. La misma deberá ser solicitada al inicio de cada proyecto.

Debido a la dinámica propia de las tecnologías de comunicación, la información de esta Guía, podrá actualizarse periódicamente. Para cada proyecto se establecerá cuál es la versión de los lineamientos a aplicar. Los mismos serán de obligatorio cumplimiento por parte de las entidades a las cuales se refiere la presente resolución.

Documentos para descargar:

Normativa de Usabilidad y Accesibilidad Web (pdf)

Guía Web – Primera Versión (pdf)

1. Comprender los objetivos del sitio.
2. Analizar quienes van a ser los usuarios.
3. Armar la arquitectura de la información.
4. Definir los rótulos.
5. y luego recién … armar el diseño visual.

1. Comprender los objetivos del Sitio:

Esto nos permitirá:

• Reconocer las tareas principales.
• Diseñar enfocados.
• Pensar cuántos niveles de profundidad le vamos a otorgar a cada ítem (o sea, cuántos clicks deberá hacer el usuario para llegar a la información que busca).

2.  Analizar quiénes van a ser los usuarios:

Saber esto nos permitirá diseñar en función de su edad, conocimiento técnico, necesidades y expectativas.

3. Armar la arquitectura de la información:

• Hacer un inventario de los contenidos.
• Verificar si hay elementos innecesarios que se pueden eliminar.
• Agrupar, jerarquizar y estructurar la información.
• Generar el mapa del sitio.
• y bosquejar posibles estructuras para comenzar a hacer pruebas con usuarios.

Detalle: No es necesario volcar la burocracia de las instituciones en la organización de nuestros sitios. El objetivo es reagrupar y reestructurar lógicamente la información, para facilitar las búsquedas.

4. Definir los rótulos:

Hay una gran diferencia entre un sitio de entretenimientos, donde el usuario dispone tiempo para experimentar, y uno informativo, donde el objetivo del usuario es terminar sus tareas de manera fácil y rápida.

Para esto debemos:

• Generar rótulos claros y explícitos.

Hay sitios públicos que parecen un juego siniestro donde se le dice a la gente “a que no adivinás a dónde vas si hacés click acá”…. Y el usuario necesita ingresar a todas las secciones para tratar de encontrar lo que busca.

(Yo no sé si es desconocimiento o perversión).

• Usar el lenguaje del usuario.

Trabajé para un formulario de búsqueda avanzada en el sector de educación, donde la opción para elegir colegio público o privado, era “gestión”. Me pregunto si todos los papás y mamás que buscan un colegio para sus hijos saben que “gestión” se refiere a esto. Quizás habría que buscar una palabra más comprensible.

5. y luego recién… armar el diseño visual.

Después, sólo después de contar con el mapa del Sitio y los wireframes probados,  conviene comenzar a bosquejar.

Esto parece obvio, pero muchos equipos de diseño enfocan sus recursos en que los sitios queden bellos; olvidando y dejando de lado, todo lo relacionado al mundo funcional!

¿Cómo reconocemos los objetivos de los usuarios?

Pocas veces los usuarios logran definir sus propios objetivos, por eso somos nosotros quienes debemos deducirlos y reconstruirlos a partir de entrevistas.

Niveles de procesamiento:

Don Norman en su libro “Emotional Design” distingue 3 niveles cognitivos y emocionales de procesamiento de un usuario frente a un producto:

• Visceral: Es el nivel inmediato, en el cual el usuario reacciona a aspectos visuales o sensoriales antes de interactuar. Ej. Formas y colores.
• De comportamiento: Aquí la persona se relaciona con el funcionamiento del sitio y las actividades que puede hacer a través de la interacción.
• Reflexivo: Este nivel requiere experiencia, memoria y reflexión.

Diseñar enfocados en los distintos niveles de procesamiento:

Alan Cooper en su libro “About Face 3” distingue 3 formas de diseñar:

• Diseñar para la respuesta visceral: Significa apuntar a cuestiones estéticas y afectivas.
• Diseñar para el comportamiento: Implica diseñar para un modelo mental determinado.
• Diseñar para la reflexión: Implica construir una relación duradera entre el usuario y el producto.

y considera distintos tipos de objetivos, los cuales podemos satisfacer con estos niveles de diseño.

Objetivos de los usuarios:

1. Objetivos relacionados con la experiencia sensorial (Experience goals):

• Responden a la pregunta: Cómo se siente el usuario. Ejemplo: En control / Inteligente / Divertido / Relajado / Alerta.
• Se relacionan con el nivel visceral.
• (Este será el puente para que la persona comience a interactuar).

2. Objetivos finales (End goals):

• Responden a la pregunta: Para qué se usa el sitio.
• Se relacionan con el nivel de comportamiento.
• Son el foco del producto y la arquitectura de la información: Ejemplo: Estar conectado con la familia y amigos / Encontrar música que a uno le gusta/ etc.

3. Objetivos de vida (Life goals):

• Responden a la pregunta: Por qué se usa el sitio.
• Apuntan al nivel reflexivo.
• Representan las aspiraciones personales. Ejemplo: Ser buena persona / Ser un buen ciudadano / Ser atractivo / Ser popular / etc.

Si un usuario descubre que un producto simpatiza con sus objetivos de vida, se generará sin dudas una relación duradera.

Hacer un análisis de nuestros potenciales usuarios, nos permitirá llegar a sus objetivos de vida y generar una mayor satisfacción en su experiencia como usuarios.

Fuente:

“About Face 3″, Alan Cooper

Implica reemplazar el trabajo en abstracto para diseñar focalizados en alguien específico, analizando la importancia de cada tarea según la mirada de nuestro personaje representativo (que contará con el modelo mental de los usuarios a quienes estamos apuntando).

Caracteríticas de nuestros personajes:

Concretos: Reemplazarán a los usuarios generales. Serán más específicos que un perfil y contarán con nombre, apellido y una ficha con sus características, intereses y objetivos.

Representativos: Contarán con el modelo mental del grupo de personas que ingresará al Sitio (en caso de que existieran distintas áreas de funcionalidad, crearemos distintos roles).

Definidos: Deben ser capaces de contestar qué cosas son necesarias de incluir en el diseño y qué cosas pueden quedar afuera.

No son reusables: Son construidos para un contexto específico.

No son estereotipos: No están basados en prejuicios ni suposiciones caricaturescos. Si el diseñador no respeta al usuario nadie lo hará!

Muestran motivaciones y objetivos: Tanto obvios como sutiles.

Beneficios de crear personajes:

Alan Cooper, en su libro “About Face 3″ describe los siguientes beneficios:

Comunicación: Provee un lenguaje común para las discusiones de equipos interdisciplinarios.

Precisión: Determina como debe ser el producto y cómo se debe comportar.

Medición: Mide la efectividad de un diseño. Sirve para testear decisiones.

Foco: Mantiene a los diseñadores centrados en el usuario durante todo el proceso de desarrollo.

Consenso: Facilita el concenso, dado que es fácil de entender y de relacionar cada personaje con su listado de necesidades.

Evita el usuario elástico: Torcer o estirar nuestro referente imaginario para adecuarse a las opiniones o presuposiciones de cada diseñador.

Previene el diseño auto-referencial: Cuando diseñamos para nuestros propios objetivos o nuestro modelo mental.

Impide centrarnos en casos inusuales: Proviene centrarnos en situaciones que podrían llegar a pasar pero que en realidad casi no suceden y no deberían ser el objeto de nuestros esfuerzos

Para poder crear nuestro personaje, es necesario sumar al requerimiento planteado por el cliente, los resultados de entrevistas con usuarios potenciales. Esto nos permitirá diseñar enfocados en sus verdaderas necesidades.

Fuentes:

“Pensar Primero” de Daniel Mordecki http://www.mordecki.com/libro/descargarlibro/descargarlibro.shtml

“About Face 3″, Alan Cooper

HTML es un lenguaje basado en etiquetas donde las posiciones y funciones de cada elemento en la estructura del Sitio están indicadas mediante tags.

Un menú es un listado de links (verticales u horizontales) y deben estar contenidos con las etiquetas de listas <ul> u <ol>.

Por lo tanto:

• En caso de que se desactiven los estilos (CSS) la botonera se visualizará como un conjunto de links agrupados.
• Los lectores de pantalla – que no interpretan el Sitio visualmente, sino a partir de cómo está formulado el código – comprenderán y podrán transmitir correctamente la estructura al usuario no vidente.

¿Cómo creamos una botonera con una lista (ul / ol)?

Generamos una división (div) con una lista (ul / ol), donde cada ítem (li) será un link (a) con imágenes de fondo diferentes para cada uno de sus estados (esta técnica es conocida como Sprite).

Ejemplo de botonera:

En este ejemplo, las imágenes de los botones cuentan con los rótulos.

<div id=’botonera’>
<ul>
<li><a href=’presentacion.php’  id=’presentacion’><span>Presentaci&oacute;n</span></a></li>
<li><a href=’centro.php’ id=’centro’><span>Centro de Documentaci&oacute;n</span></a></li>
<li><a href=’legislacion.php’ id=’legislacion’><span>Legislaci&oacute;n</span></a></li>
<li><a href=’estadisticas.php’ id=’estadisticas’><span>Estad&iacute;sticas</span></a></li>
<ul>
</div>

¿Qué pasaría si se desactivaran los estilos?

En caso en que se desactivaran los estilos y por lo tanto, se dejaran de mostrar las imágenes de los botones con sus rótulos, podríamos incluir dentro de cada botón un span con el texto (el cual podríamos hacer invisible mediante el estilo display:none).

<a href=’estadisticas.php’ id=’estadisticas’><span>Estad&iacute;sticas</span></a>

#botonera ul li span{
display:none;
}

Este texto se mostrará en lugar de las imágenes, en caso de que se desactive el CSS.

¿Los lectores de pantalla para no videntes interpretan un rótulo con display:none?

El NDVA sí los interpreta. Aparentemente no sucede lo mismo con JAWS. Pienso que una solución sería repetir el menú en el pie de página, pero sin imágenes (para seguir pensando).

¿Cómo le incorporamos una imagen a un link?

Indicando Display:block le generamos a los enlaces un alto y ancho y esto nos permitirá incluirles una imagen de fondo.

#botonera ul li a
{
display:block;
width:9em;
height:3.2em;
}

¿Cómo incluimos imágenes para los distintos estados?

Una opción sería incluir una imagen en el background de cada link y modificar su posición (background-position: top o bottom) según el estado del botón (a esta técnica se la llama Sprite).

#botonera ul li a#presentacion{
display:block;
width:9em;
height:3.2em;
background-image:url(../img/01presentacion.jpg);
background-repeat:no-repeat;
background-position: top;
}

#botonera ul li a#presentacion:hover{
width:9em;
height:3.2em;
display:block;
background-image:url(../img/01presentacion.jpg);
background-repeat:no-repeat;
background-position: bottom;
}

… y para concluir nuestra botonera, ¿cómo eliminamos los bullets de la lista?

#botonera ul
{
list-style: none;
padding: 0;
margin: 0;
}

¿Y cómo hacemos que la botonera sea horizontal?

La propiedad float, permite que los ítems “floten” uno al lado del otro.

#botonera li
{
float: left;
}

Así lograremos hacer una botonera con:

• Imágenes para los distintos estados con la técnica sprite.
• Que aparecerá como un listado de links, en caso de que estén desactivados los estilos.
  

Colaboración: Programadora Daniela Rositto

• Utilizar unidades relativas permite a las personas con problemas de visión cambiar las preferencias del navegador y de este modo modificar los tamaños de los textos e imágenes de los Sitios a los que acceden.
• Y permite a las personas que todavía utilizan IExplorer 6, utilizar la función Ctrl+ ó – para hacer zoom (dado que en esta versión, los elementos en pixels no se amplían y sólo lo hacen los que están especificados en EM).

¿Cuál es la diferencia entre ambas formas de trabajo?

• Si utilizamos unidades absolutas (pixels, puntos, etc.) cuando los usuarios modifiquen las preferencias del navegador, los elementos no se verán afectados.

UNIDADES ABSOLUTAS => DISEÑO RÍGIDO
=> EL USUARIO DEBERÁ ATENERSE A LAS PREFERENCIAS DEL DISEÑADOR.

• En cambio, si utilizamos unidades relativas (por ejemplo, EM) los textos e imágenes van a ampliarse o achicarse según lo decida el usuario.

UNIDADES RELATIVAS => DISEÑO ELÁSTICO
=> EL USUARIO DECIDE.

¿Cómo podemos llevar nuestros diseños armados en PX a esta medida relativa?

Para poder sincronizar el diseño armado en pixels con la maquetación en EM, podemos hacer que 1 EM sea igual a 10 px (esto es simplemente para hacer las cuentas más fáciles!).

Dado que la tipografía predeterminada del navegador viene preestablecida en 16 px, si establecemos el font-size al 62.5% (62.5 % de 16 px = 10 px) estamos fijando que 1 em sean 10 px.

body {

font-size: 62.5%;

}

Por lo tanto:

• 1 EM = 10 PX
• 1.2 EM = 12 PX
• 1.3 EM = 13 PX
• 2 EM = 20 PX

¿Cómo hacemos para que nuestros diseños no se desarmen en caso de que el usuario modifique el tamaño predeterminado?
Entiendo que tenemos dos posibilidades:

1)      Utilizar los EM para TODOS LOS ELEMENTOS (divs,  textos e incluso imágenes) y de este modo, todo aumentará proporcionalmente.

2)      Hacer una mixtura: armar la maquetación de forma rígida (en pixels) y sólo las fuentes determinarlas en EM. Pero para esto deberíamos preparar el diseño teniendo en cuenta qué pasaría si el usuario decidiera aumentar la fuente, por ejemplo, al 200%.

Los invito a ver cómo está armado el código fuente de este mismo WordPress Themes, programador por Rodrigo Galindez.

]]> http://www.veronicatraynor.com.ar/unidades-relativas-para-beneficiar-a-los-usuarios-con-problemas-de-vision/feed/ 4 http://www.veronicatraynor.com.ar/checklist-de-accesibilidad-para-el-area-de-maquetacion/ http://www.veronicatraynor.com.ar/checklist-de-accesibilidad-para-el-area-de-maquetacion/#comments Fri, 29 Jan 2010 23:02:27 +0000 Verónica Traynor http://www.veronicatraynor.com.ar/?p=147 Actualización: 09/02/10

Con el fin de que nuestros Sitios sean perceptibles, comprensibles, compatibles y operables generamos este listado de verificación para maquetadores (para seguir revisando!).

• HTML Y CSS

1. ¿Las etiquetas utilizadas son sintácticamente correctas?
2. ¿Están íntegramente independizados los estilos a través de CSS?
3. ¿El uso de tablas se restringe a la tabulación de datos y no para diagramar el contenido del Sitio Web?
4. ¿Se puede navegar el Sitio íntegramente (incluyendo objetos incrustados) a través de un teclado?

• Compatibilidad con Navegadores

1. ¿El Sitio es compatible con el navegador Internet Explorer 6?
2. ¿El Sitio es compatible con el navegador Internet Explorer 7?
3. ¿El Sitio es compatible con el navegador Internet Explorer 8?
4. ¿El Sitio es compatible con el navegador Mozilla Firefox?
5. ¿El Sitio es compatible con el navegador Safari?
6. ¿El sitio es compatible con un lector de pantalla como JAWS o NVDA?

• Identificación del lenguaje:

1. El lenguaje está identificado de esta forma: <HTML lang=”es”>
2. Las abreviaturas se encuentran señaladas con el atributo <abbr>? (Ejemplo “Alte”: <abbr title=”Almirante”>Alte.</abbr>)
3. Las abreviaturas se encuentran restringida a las definidas por la Real Academia Española (Evitando por ejemplo “ascend.” para decir “ascendente”)
4. ¿Los acrónimos se encuentran señalados con el atributo <acronym>? Ejemplo: “GCBA”: <acronym title=”Gobierno de la Ciudad de Buenos Aires”> GCBA </acronym>)
5. ¿Las etiquetas <abbr> y <acronym> han sido utilizadas exclusivamente para su función y no para mostrar como “tooltip” información adicional de otra naturaleza? (Ejemplo de mala práctica: <acronym title=”Founded in 2006″>  Twitter </acronym>)

• Imágenes y animaciones:

1. ¿Todas las imágenes y animaciones cuentan con un texto alternativo?
2. ¿Los textos alternativos representan una alternativa válida para transmitir la misma información que comunica el formato no textual? (NOTA: Quien elabore el contenido debe proveer el texto alternativo para las imágenes informativas, de forma que el programador pueda incluirlas) Ejemplos: El texto alternativo de un banner debe incluir la descripción de los objetos y/o textos que figuren en la imagen. No debe decir “banner”.El texto alternativo de una flecha (botón) debe decir “siguiente” o “volver”. No debe decir “flecha”.
3. ¿Todas las animaciones pueden ser controladas (pausadas) por el usuario?

• Multimedia:

1. ¿Los audiovisuales o archivos de audio se encuentran subtitulados o incluyen el texto en un archivo tipo HTML u opciones Word o PDF accesible?
2. ¿La voz principal se distingue con facilidad del sonido ambiente?

• PDF:

1. ¿Los documentos PDF pueden ser interpretados por un lector de pantallas para no videntes? (Validar con un lector de pantallas Ejemplo NVDA )
2. Las imágenes del PDF ¿cuentan con un texto alternativo?
3. Si un documento PDF no fuera accesible, ¿existe una versión alternativa accesible en Word o HTML?
4. ¿Todos los enlaces se encuentran acompañados con el ícono identificativo de Adobe PDF?
5. ¿Todos los enlaces PDF abren en una nueva ventana?

• Formularios: Carteles de error:

1. ¿Evitan el lenguaje técnico, utilizando un lenguaje claro y comprensible por los usuarios?
2. ¿Señalan claramente el campo en cuestión (no basándose sólo en el color, sino, acompañándolo también de un icono)?

• Enlaces

1. ¿El Sitio es navegable con JavaScript desactivado?
2. ¿Se encuentran los menúes (horizontales y verticales) armados con listas OL o UL?
3. ¿Se encuentran todas las rutas verificadas de tal modo que ninguna lleve a una ruta equivocada o inexistente?

• Validadores:

1. W3C
2. SIDAR
3. Accesibilidad.com
4. Lector de Pantallas NVDA

ver Checklist de accesibilidad para el área de diseño

Este checklist fue una idea que Santiago Bustelo propuso al GCBA para verificar los diseños antes de ser subidos a producción.
También fue debatido en los foros Acceso Web e IXDA.

Con el fin de que nuestros diseños sean perceptibles y comprensibles, generamos este listado de verificación (para seguir revisando!).

• Sobre la navegación:

1. En caso de contar con sub-secciones ¿Incluye Mapa de Sitio o Tabla de Contenidos?
2. ¿Los elementos comunes están localizados en la misma posición en todas las pantallas?
3. ¿Los elementos interactivos se comportan de la misma forma todas las veces que aparecen?

• Sobre los textos:

1. ¿Se distingue el color de los textos de su color de fondo?
2. ¿El tamaño de las tipografías no es de menor que 10px (1 em)?

• Sobre los enlaces:

1. ¿Se diferencian los enlaces del resto de los textos por su color, subrayado u otra característica?
2. ¿Cuentan todos los links – ya sean textos, botones o íconos – con estado Roll Over?
   (Se satisface con el atributo de CSS a:hover)
3. ¿Queda señalada la solapa (botón/link) dónde se encuentra el usuario?
4. ¿Los textos de los enlaces son lo suficientemente explícitos en su destino?
5. ¿No existen hipervínculos distinguidos con las frases “click aquí” o “+ info”?

• Sobre los colores:

1. ¿La información transmitida a través de los colores también está disponible sin color?

Validadores:

Validador de color SIDAR
Descargar aplicación de Paciello Group para validar contrastes de colores.

ver Checklist de accesibilidad para el área de maquetación

Este checklist fue una idea que Santiago Bustelo propuso al GCBA para verificar los diseños antes de ser subidos a producción.
También fue debatido en los foros Acceso Web e IXDA.

• Es una imagen con caracteres distorsionados (números y/o letras) para que las personas identifiquen y reescriban.
• Suele incluirse como paso previo antes de enviar un formulario o al ingresar a una aplicación como forma de seguridad.
• y dado que el desafío no lo podrá resolver una máquina para enviar comentarios automáticos (spam), esta no podrá ingresar.

¿Cuál es la problemática del CAPTCHA?

El inconveniente es que las personas con:

• baja o nula visión
• daltonismo
• problemas cognitivos
• o bajos niveles de educació

… pueden fallar reiteradamente en entender los caracteres y no podrán acceder (quedando del mismo lado que los robots programados!).

Inclusión de un campo oculto como alternativa más accesible:

Una opción sería incorporar un CAPTCHA sonoro; pero otra posibilidad, sería incluir un campo invisible (que para los no videntes aclare que no debe ser completado). Y programar que si el campo se completa, no se realice el envío.

Las personas no lo completarán, pero los robots automatizados sí.

Y de este modo se les bloqueará el acceso.

Ejemplo de código:

<html>
<head>
<title>Formulario con campo oculto</title>

<style>
#oculto{ display:none;}
</style>

<?php

if(isset($_POST['oculto'])&&($_POST['oculto']!=”"))
{
echo ‘es un robot’;
}
else {if(isset($_POST['nombre'], $_POST['apellido']))
{
echo ‘es una persona’;
}
}
?>
</head>

<body>

<form action=”formulario.php” method=”post” enctype=”multipart/form-data”>
<label title=”nombre”>Nombre:</label><input type=”text” />
<label title=”apellido”>Apellido:</label><input type=”text” />
<input name=”oculto”/>
<input value=”Enviar” />
</form>

</body>
</html>

Esta alternativa impediría que los robots spammers puedan ingresar,  siempre y cuando nadie programe específicamente uno contra nuestro sitio.

Colaboración: Programadora Daniela Rositto