Más información en Workshop WCAG 2.0 y HTML5 – Madrid, mayo 2012

Lo cual no deja de ser curioso que su creador tenga un problema de compresión con ciertos colores y que Facebook haya sido reclamada en más de una ocasión por su inaccesibilidad.

Fuente y más artículos relacionados con el daltonismo: ¿Por qué el logo de Facebook es azul?

Pero, ¿qué ocurre cuando ante varias insistencias y comentarios a la empresa sobre la accesibilidad de su sitio web o de alguna funcionalidad del mismo no se obtiene ninguna respuesta?

personal de @ @ono_ono intento ver mi factura en su web pero no es #accesible. Lo pensáis arreglar?

@rosalamala

A todo mi tl. preguntad a @ono_ono sobre la accesibilidad de su web, a ver si os contestan o dan la callada por respuesta como a mí. tu aplicación será accesible.

@kastwey

Estoy hasta las narices de los correos inaccesibles de @ono_ono, yo soy un cliente igual que los demás, por lo menos me cobran lo mismop

@jmortizsilva

Tal vez, el siguiente paso sea realizar oficialmente una consulta/queja o una denuncia.

No obstante, como bien dice un usuario en un comentario de la entrada original una de las cosas que mejor funcionan es (aparte de seguir los correspondientes cauces de reclamación) crear ruido mediante los medios de comunicación y la verdad es que ahora con Twitter incluso también.

Fuente: Guía para la autodefensa de las personas con discapacidad

Aquí en España se han realizado denuncias de este tipo tras haber ignorado las compañías los consejos e informes de accesibilidad realizados. La diferencia con el Reino Unido es que mientras aquí, aunque exista la denuncia y la queja nunca ocurre nada y la cosa suele seguir igual, probablemente allí tengan consecuencias y la compañía se vea obligada a realizar cambios.

Fuente: Denuncia de RNIB contra la compañía aérea bmibaby

Fuente: Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

Para el encuentro de este mes se abordarán los problemas habituales en el uso de CAPTCHAs y se debatirá sobre el listado existente de páginas webs denunciadas por no ser accesibles.

La reunión de Marzo tendrá lugar en la Sala Ciball (Corredera Baja de San Pablo número 41), el 18 de Abril a las 19:00 horas.

Más información y asistentes en: Encuentro Accesibilidad Abril

Una de las características de la herramienta es la realidad del personaje utilizado para la traducción en lengua de signos. A dicho personaje o avatar lo han llamado Maya. Las posibilidades de esta herramienta son bastante amplias.

Fuente: Maya, un avatar virtual, es la primera traductora simultánea de páginas web en lengua de signos

La reunión de Marzo tendrá lugar en la Sala Ciball (Corredera Baja de San Pablo número 41), el 14 de Marzo a las 19:00 horas.

Más información y asistentes en: Encuentro Accesibilidad Marzo

Aplicaciones accesibles

Con independencia al sistema operativo para el que se desarrollen las aplicaciones, los diseñadores de éstas deben aplicar un conjunto de requisitos de accesibilidad para garantizar que las personas con discapacidad, mayores y otros colectivos puedan hacer uso de las mismas. Estos requisitos son:

1. La aplicación del cliente, que es la que se instala en el dispositivo móvil, debe ser accesible. Para comprobar su accesibilidad, resulta necesario interactuar con la misma con productos de apoyo instalados (lector de pantalla, magnificador, etc.). Para que la aplicación sea accesible, los contenidos visuales deben disponer de alternativa, los formularios deben estar correctamente etiquetados, el orden de lectura de los elementos debe ser adecuado, el contraste ha de ser suficiente, los controles deben tener un nombre representativo, etc.
2. La aplicación debe permitir ciertos niveles de personalización, como tamaño de fuente, colores del interfaz, nivel de audio, velocidad en respuesta de los procesos tempodependientes, etc. También se debe tener en cuenta el uso de personalizaciones del sistema: si el usuario ha definido un tema de alto contraste para su dispositivo, el interfaz del servicio de Internet debe tenerlo en cuenta y ser compatible con él.
3. Durante el uso de una aplicación cliente, el usuario debe obtener algún tipo de ayuda o guía para una experiencia de uso satisfactoria. El interfaz del cliente debe proporcionar esta guía utilizando mecanismos de ayuda como pueden ser: etiquetas de instrucciones en el interfaz, globos de ayuda, imágenes aclaratorias, animaciones explicativas, etc. Los mecanismos empleados deben ser accesibles para los productos de apoyo compatibles con la plataforma del cliente.
4. La aplicación debe notificar al usuario el estado en que se encuentra: activo/pausado, en configuración, desactivado, no disponibilidad del servicio, en progreso de finalización de una operación (transferencia o recepción de información o similar), etc. La notificación debe realizarse a través de los mecanismos de notificación del dispositivo móvil para que resulte accesible. No se deben emplear notificaciones visuales incrustadas en el interfaz del cliente, ya que este tipo de notificaciones, en la mayoría de los casos, resultan inaccesibles para algún perfil de usuario.
5. El usuario debe poder activar, pausar y parar el servicio prestado mediante la aplicación a voluntad mediante un mecanismo accesible desde su interfaz.
6. La interfaz de una aplicación cliente no debe estar sobrecargada con multitud de controles y datos en pantalla. Se debe simplificar la interfaz visualizada con algún mecanismo de agrupación, como pueden ser pestañas de selección, navegación estructurada por menús o uso de múltiples ventanas.
7. Si la aplicación posee la posibilidad de utilizar otros idiomas en su interfaz se debe verificar que todos los elementos (leyendas de botones, mensajes de estado, títulos, ayudas y alternativas a imágenes, etc.) están correctamente traducidos al idioma seleccionado.
8. La aplicación debe proporcionar un mecanismo de configuración y personalización mediante asistente que guíe al usuario durante el proceso de configuración. El proceso debe ser claro, progresivo y acompañado de ayudas y notificaciones de errores con sugerencias que ayuden al usuario a cumplimentar la configuración de la aplicación.
9. La ayuda relacionada con una aplicación debe ser clara y comprensible. Se debe incluir información sobre el uso y configuración del servicio, una lista de errores posibles que puede notificar la aplicación durante su utilización y una guía de preguntas frecuentes.
10. La aplicación debe proporcionar algún mecanismo de recuperación de información tras un error producido durante un proceso como, por ejemplo, la configuración o personalización de la aplicación (utilizando un asistente de varios pasos), la transferencia o recepción de archivos o recursos, etc.
11. Si la aplicación posee algún proceso tempodependiente (aceptar una petición de conversación, llamada, envío, etc., visualización de mensajes de ayuda o información, etc.) el proceso debe finalizarse a petición del usuario, mediante un mecanismo de aceptación/cancelación o un tiempo definible por el usuario.
12. Si un servicio requiere de pagos para disfrutar de él debe ir acompañado de notificaciones claras de cuánto va a costar el uso de ese servicio.
13. La aplicación debe proteger la información personal del usuario, si el usuario modifica alguna característica de sus opciones de configuración, el servicio debe notificar del hecho de que el cambio puede hacer visible su información personal relacionada con dicha opción de la configuración. El servicio debería informar al usuario del estado de sus datos privados mencionando, si es posible, el organismo de certificación de seguridad empleado.
14. Muchas aplicaciones parten de una Web para su descarga o muestran contenidos Web mediante un navegador. En el caso de que parte de los contenidos sean Web, se han de aplicar los requisitos recogidos en el apartado destinado a la web móvil.

Web móvil accesible

1. El propósito u objetivo de los contenidos debe ser claro y obvio. Con un solo vistazo, el usuario debe comprender qué ofrece la página y con qué finalidad, además de que haya un solo propósito en los contenidos.
2. La información más relevante debe preceder al material cuyo contenido sea menos importante. Resulta fundamental asegurarse de que el material cuyo significado es importante en la página precede al que no lo es, evitando al usuario tener que utilizar la barra de desplazamiento para buscar el contenido principal de la página. Así, el usuario se hará una idea del contenido principal de la página la primera vez que la vea. Esto puede ayudar a los usuarios a determinar cuando la información interesa y si no es así, saltarla.
3. La página donde se presenta el servicio o la información debe contener un título corto pero descriptivo. En muchos navegadores móviles no se muestra el título de la página. Donde se muestra el título el espacio puede ser limitado. El título ayudará a la página a identificarse fácilmente. Los dispositivos móviles pueden utilizar el título de la página como una etiqueta por defecto para los favoritos.
4. Utilizar un lenguaje simple y claro. La lógica de presentación de los contenidos debe ser familiar o comprensible para el usuario y el nivel de conocimientos coincidir con el nivel del usuario. El uso de lenguaje claro tiene una importancia particular en el contexto de los móviles, donde se prefiere un estilo breve y directo frente a uno divagador, ya que el texto se muestra en una fuente de texto pequeña y el usuario normalmente se distrae por condiciones ambientales y fácilmente puede sentirse perdido o confuso.
5. Los procesos han de ser sencillos para el usuario. Para facilitar al usuario la realización de procesos, habrá que tener en cuenta los siguientes factores:
   1. Que esté indicado el número de paso del proceso y los pasos restantes.
   2. Que se evite el uso de información oculta que requiera de una acción para su visualización.
   3. Que se informe del feedback cuando la acción aún está en proceso.
   4. Que se informe del feedback cuando una acción ha sido realizada con éxito o no.
   5. Que el feedback sea inmediato y sin retraso, (de 1 a 10 segundos).
   6. Que sea posible volver al paso/s anterior/es del proceso para modificarlo/s.
   7. Que exista una salida de la página, del proceso o de la estructura de información, mediante Desconectar o Cancelar.
   8. Que las mismas acciones lleven a los mismos resultados.
   9. Que sea posible deshacer una acción siempre que sea una opción funcional y operativa.
6. Utilizar las características de marcado para indicar la estructura lógica del documento. Se debe definir la estructura de los contenidos, de forma correcta, mediante encabezados y agrupar los elementos mediante listas.
7. Proporcionar mecanismos de navegación consistentes. Los sitios web deben disponer de un mapa web o una barra de navegación o un menú de contenidos. Además, se debe poder llegar a algunos de estos elementos de navegación desde la página de inicio o página principal. En el caso de presentarse varias opciones de un mismo menú, éstas requieren ser ordenadas de manera lógica para la forma de pensar del usuario. Agrupar de forma inteligente varios conceptos ayudará a la usabilidad. Eso sí, las opciones de navegación deben ser similares en toda la aplicación o servicio web y la misma información se debe expresar del mismo modo en todo el sitio donde se presenta el contenido o se prestan unos servicios. Por último, debería existir un vínculo que permita volver a la página inicial desde cualquier página.
8. Se debe ofrecer una barra de navegación mínima en la parte superior de las páginas, ofreciendo enlaces básicos en una sola línea. Los elementos de navegación secundarios pueden estar colocados en la parte inferior de la página. No olvidar que los usuarios deben ser capaces de ver el contenido de la página una vez que la página se ha cargado sin desplazamientos o Scrolling.
9. Evitar el inicio automático de acciones que el usuario no ha ordenado explícitamente. El auto-refresco crea confusión a los usuarios de lectores de pantalla. Por ejemplo, cuando un usuario está leyendo una página, el auto-refresco puede provocar que el lector de pantalla vuelva a leer el contenido actualizado desde el principio y confundir al usuario (pierde el foco en la página).
10. Hay que asegurarse que el contenido obtenido, accediendo a través de una URI, produce una experiencia coherente cuando se accede desde diferentes dispositivos. El contenido debe visualizarse adecuadamente con diferentes resoluciones y mostrarse éste de forma similar desde cualquier dispositivo. Además, se debe poder activar cualquier elemento de la aplicación o página desde distintos dispositivos.
11. Las metáforas e iconos que se utilicen deben ser comprensibles para el usuario, facilitando la interacción con la página. Los iconos e imágenes deben ayudar a facilitar la comprensión del contenido. Con unos iconos fáciles de entender se aumentará la accesibilidad del sitio.
12. Resaltar el formato del fichero de entrada. Los usuarios de los dispositivos móviles sufren retraso excesivo y un coste como resultado de acceder a ciertos enlaces, por lo que es importante identificar hacia dónde se dirige el enlace de manera que los usuarios puedan hacer una evaluación de si estarían interesados o no en seguir dicho enlace. Es aconsejable indicar el formato de fichero en los enlaces a contenido que está en un diferente formato o diferente lenguaje a la página del enlace (sería aconsejable indicar también el tamaño del recurso), de manera que los usuarios no tengan que bajarse el contenido si no lo consideran prioritario.
13. Se debe evitar la apertura de ventanas emergentes o ventanas pop-ups, ya que no todos los dispositivos móviles soportan más de una ventana. No se debe cambiar de la ventana actual sin informar antes al usuario en el enlace o botón que provoque dicho cambio.
14. Los errores que puedan ocurrir y puedan ser controlados por los desarrolladores, deben estar escritos en lenguaje común y no con códigos o lenguaje técnico, informando de la causa del error de manera que se pueda evitar su repetición en el futuro. Sería aconsejable también que se den soluciones o sugerencias para solucionar el presente error. Eso sí, se debe permitir que el usuario pueda salir del lugar donde se produjo el error.
15. Evitar, en lo posible, la entrada de texto libre y mejor ver y seleccionar que tener que recordar y escribir. Además, es mejor poder seleccionar la información en situaciones donde se pueden producir errores en la escritura.
16. Mantener al mínimo el número de pulsaciones de teclas. Debido a las limitaciones típicas de los dispositivos móviles para la entrada de datos en la interfaz, se deben minimizar en lo posible las entradas de los usuarios. Cuando sea posible, hay que usar listas de selección, radio botones y otros controles con los que no se requiera que el usuario escriba.
17. Proporcionar valores por defecto cuando sea posible. Especificar un modo de entrada de texto por defecto. Comprobar si el contenido o servicio prestado especifica o da un ejemplo sobre cómo debe introducirse la información en campos problemáticos indicando el formato de entrada (por ejemplo, fecha 00/00/000 ó 00/00/00 o, por ejemplo, cantidades 1000 ó 1.000 y 11,11 ó 11.11). Cuando sea posible se deben utilizar las últimas entradas como entradas por defecto.
18. Para evitar el uso del teclado (incómodo en la mayoría de los dispositivos móviles), debería darse la posibilidad de utilizar aceleradores o atajos para realizar operaciones frecuentes.
19. En los controles de entrada de datos de los formularios (caja de texto, por ejemplo), debería estar siempre indicada la posición del cursor. Cuando se abra una página con un formulario, el cursor debería aparecer parpadeante en el primer campo del formulario a completar.
20. Mantener las URIs de los puntos de entrada de un sitio con longitud corta. Teclear las URIs en dispositivos móviles puede ser difícil. Aunque los usuarios preferirán usar métodos alternativos para obtener las URIs (hiperenlace, por ejemplo), a veces el tener que teclear una URI puede ser en algunos casos la única opción disponible y a la hora de introducir dicha URI de un sitio que ésta pueda tener la longitud más corta posible.
21. Mantener el número de recursos externos al mínimo. Cada recurso (imágenes, hojas de estilo y otros elementos de la página externos) requiere una petición diferente a través de la red, suponiendo más tiempo para cargar la página. Por tanto, es necesario comprobar que haya el mínimo número de recursos externos posibles en la página (menos de 20). Además, el número de iconos por página debe ser como máximo 15 y, a su vez, el número de recursos gráficos en la página no puede ser más de 7.
22. Asegurarse que el tamaño total de la página (marcado e imágenes) es apropiado para las limitaciones de memoria del dispositivo. Si las páginas son muy grandes, se tarda mucho tiempo en cargarlas, y esto puede acarrear problemas en algunos dispositivos móviles que suelen tener restricciones sobre cuál es el tamaño máximo de la página que pueden cargar.
23. Evitar imágenes de gran tamaño que no pueden ser interpretadas por el dispositivo. No utilizar imágenes que no pueden ser interpretadas por el dispositivo, imágenes grandes o de gran resolución, excepto donde la información sea crítica y en el caso contrario pudiera perderse.
24. La página se debe presentar de tal manera que el scroll vaya en dirección vertical, permitiendo que el usuario pueda tener una buena experiencia en todo el contenido. Sin embargo, algún tipo de contenido (como mapas e imágenes) no puede ser visto sin utilizar el scroll secundario (horizontal). Si un elemento de la página necesita el scroll secundario, no se debe hacer que el resto de la página lo requiera.
25. Preservar la privacidad de entrada de datos confidenciales. Se debe proteger la contraseña o palabra clave para que no pueda ser vista en pantalla. Por ejemplo, mostrando asteriscos o caracteres especiales en lugar de los caracteres introducidos, “*****”.
26. Los contenidos y funcionalidades deben basarse en tecnologías que sean accesibles con productos de apoyo y puedan soportarse en los dispositivos.
27. El código utilizado para desarrollar la página requiere ajustarse a las gramáticas formales y que se trate de un código eficiente.
28. Como cada vez los dispositivos son más avanzados, hay que aprovechar, al máximo, las capacidades del dispositivo para proporcionar una mejor experiencia al usuario en dispositivos más capaces. No quedarse sólo en páginas exageradamente simples.
29. El contenido debe ser enviado en un formato que sea soportado por el dispositivo. Transferir contenido que el dispositivo no puede mostrar hace que el usuario pierda tiempo y dinero. Un dispositivo puede expresar cuáles son sus formatos preferidos. En este caso, es una buena práctica respetar las preferencias del dispositivo, de manera que se implementen estos formatos de una forma más completa.
30. Evitar el uso de tablas para posicionar los elementos en la página. Las tablas no funcionan bien en pantallas cuyo tamaño está limitado y pueden provocar que el usuario deba utilizar el scroll horizontal para leerlas.
31. El uso de marcos queda totalmente prohibido. Muchos dispositivos móviles no soportan marcos y, por experiencia, se ha comprobado que los marcos, a la mayoría de los usuarios, especialmente a aquellos que utilizan productos de apoyo, les causan problemas.
32. Evitar los gráficos para crear espacios en blanco. Utilizar gráficos para posicionamiento absoluto no funciona en diferentes pantallas y el abuso de gráficos o gráficos que sean grandes malgastan ancho de banda.
33. Las tablas no funcionan bien en pantallas cuyo tamaño está limitado y pueden provocar que el usuario deba utilizar el scroll horizontal para leerlas. Si el usuario puede soportarlas y hay datos tabulados, es necesario que se marquen los encabezados y se relacionen correctamente las celdas de datos con los encabezados. Sería aconsejable, siempre que sea posible, usar una alternativa a la presentación tabular de los datos en el caso de que el dispositivo no pudiera soportar tablas. Evitar, en cualquier caso, el uso de las tablas anidadas.
34. Organizar el contenido de tal modo que se mantenga legible en caso de no soportar el dispositivo las hojas de estilos. Los dispositivos móviles ofrecen diferentes formas de soporte para las hojas de estilo. Algunas formas proporcionan implementaciones completas, incluyendo cacheo de hojas de estilo externas, otras no tienen cacheo externo de hojas de estilo o no soportan el elemento <style>, diversas implementaciones no soportan más de una hoja de estilo y, por último, a veces no se soportan las hojas de estilo de ninguna forma. Es preferible compartir la información sobre el estilo entre páginas, pero si el dispositivo no soporta el cacheo de hojas de estilo resulta que se carga la misma hoja de estilos en cada una de las páginas. Es necesario optimizar la información de estilo de tal manera que sólo contenga los estilos que se van a utilizar.
35. Evitar el uso de etiquetas o atributos de apariencia y formato incrustados en el código HTML. No depender del soporte de aspectos de estilo relacionados con tipo de letra y la fuente de los contenidos, utilizada para presentarlos, debe poder ser soportada por el dispositivo.
36. Utilizar unidades relativas en los valores de los atributos del lenguaje de marcado o en las hojas de estilo. Evitando medidas de píxel y absolutas, se permite que el navegador pueda adaptar el contenido que va a mostrar. Aparece una excepción a la regla cuando el tamaño de la imagen se especifica para un caso concreto. En este caso, las referencias a la imagen en el lenguaje de marcar podrán especificar las dimensiones exactas de la imagen en píxeles, para ayudar al navegador a ordenar la página y evitar que tenga que reordenarla después de haberla recuperado. Usar porcentajes y medidas relativas como em, ex, bolder, larger y thick.
37. Los controles del formulario deben disponer de una etiqueta próxima a los mismos y debe haber una asociación entre etiqueta y control marcada mediante código. Esto significa etiquetar todos los controles de formulario apropiadamente y asociar explícitamente las etiquetas con los controles de formulario, además de situar las etiquetas de forma que se ajusten apropiadamente en relación a los controles del formulario a los que se refieren.
38. Todo contenido o servicio al que se accede a través de un dispositivo móvil se debe diseñar de tal modo que se tenga en cuenta que muchos dispositivos móviles no soportan objetos “embebidos” o scripts. En el caso de que el dispositivo pueda soportar los scripts, se debe evitar su uso a no ser que no haya otro modo de llegar a los objetivos marcados para ese servicio o contenido.
39. Verificar que la información que se muestra con color no se vea afectada por la falta del color. Además, aAsegurarse que la combinación de color del fondo y del primer plano proporciona suficiente contraste.
40. Todas las imágenes deben tener una descripción textual alternativa adecuada al mensaje o contenido que se presenta en la imagen.
41. Siempre que se presente información en forma de vídeo se debe proporcionar una trascripción o un resumen del contenido audiovisual para quienes no pueden acceder a dichos vídeos, ya que existen dispositivos móviles que no soportan objetos de programación, como puede ser Flash.
42. Es aconsejable que, en el caso de que el dispositivo pueda soportar multimedia, existan vídeos en lengua de signos para transmitir la información más relevante.
43. Evitar siempre los destellos o parpadeos que puedan distraer al usuario. Tanto los destellos como los parpadeos, además de poder ser molestos para la mayoría de los usuarios y poder distraer al usuario, pueden presentar un riesgo para personas con epilepsia foto-sensitiva.
44. Si existe movimiento en el contenido, el usuario debe tener la opción de poder detenerlo. Este movimiento puede ser provocado por scripts, imágenes, objetos programados (applets, Flash, etc.). La importancia del movimiento depende del tamaño del contenido relativo al resto de la zona visual. Cuando una página incluye contenido móvil, se debe proporcionar un mecanismo que permita a los usuarios congelar el movimiento o actualización.

Fuente: Presentación del libro blanco para el diseño de tecnología móvil accesible y fácil de usar