Guía para desarrollar Javascript accesible

Interesante tutorial que nos enseña que problemas pueden encontrarse las personas con alguna discapacidad que le obligue a prescindir de Javascript (o usuarios con dispositivos móviles), y cómo solucionarlo.
Los mayores problemas con el que se encuentran las personas que no ejecutan javascript en sus navegadores son en la navegación (menús dinámicos), contenido oculto (accesible mediante Ajax), controles dinámicos (eventos de ratón, drag&drop, …) y confusión (la web está pensada para el uso de Javascript y no usarlo conlleva un contenido inicial deficiente).
Como resumen diría que hay que ofrecer los contenidos sin necesidad de javascript, éste sólo debe ser un apoyo, y que para comprobar si tu web es accesible lo mejor es probarlo inhabilitando el javascript en tu navegador.
Creating Accessible JavaScript
Vía / @maxkuri

Crear gráficas accesibles con jQuery y canvas

Buen plugin para jQuery que permite crear gráficas de datos accesibles mediante canvas. El script es bastante fácil de usar, se crea una tabla (sí, si, con <table>, que es para lo que se deben usar), y el script dibuja los datos en un canvas.
Ofrece la posibilidad de crear gráficas de pie, barras y líneas, para lo cual, en el class de la etiqueta canvas hay que especificar el origen y el tipo de gráfica (por ejemplo, fgCharting_src-dataTable_type-pie).
Creating accessible charts using canvas and jQuery
Vía / couch

Criticas a la guía de accesibilidad de la W3C

Si estos días hemos estado hablando de accesibilidad según la W3C, hoy nos toca de hablar de las críticas que se han realizado desde un grupo llamado WCAG Samurai, un grupo de desarrolladores liderados por Joe Clark.

Las críticas siempre nos pueden ayudar a mejorar y esperemos que al menos tomen en cuenta estos puntos para la revisión final de la WCAG 2.0.

Las críticas están agrupadas según los diferentes puntos de la WCAG 2.0:

  • Proporciona alternativas equivalentes para los sonidos y los vídeos.
  • No dependas del color únicamente.
  • Usa las etiquetas y los estilos correctamente.
  • Usa el lenguaje natural de forma clara.
  • No uses tablas para layouts.
  • Cuidado con el uso de las nuevas tecnologías.
  • Cuidado con los contenidos que cambian con el tiempo (parpadeos, …).
  • Diseña con independencia del dispositivo.
  • Usa soluciones intermedias.
  • Usa las guías y las tecnologías de la W3C.
  • Ofrece información orientativa y del contexto.

WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0

| |

W3C: fallos de accesibilidad (III)

Seguimos con los fallos más frecuentes en accesibilidad que la W3C nos recuerda.

Cambio de contexto cuando se quita el foco a un elemento en un formulario

Este error ocurre cuando un elemento de un formulario pierde el foco y cambia el contexto de la página, por ejemplo debido a que se hace un submit del formulario.

Obtener el foco de un elemento con el teclado y no poder salir usando el teclado

Este fallo no es demasiado frecuente, pero se da cuando navegando mediante el teclado, entramos en el contenido de un elemento (por ejemplo un plugin que nos muestra un formato específico como SVG) y no podemos volver al contenido principal, o salir de este elemento usando el teclado.

Tener un time-out para la sesión sin ofrecer la posibilidad de guardar la información para recuperarla cuando re-auntentiquemos

Muchos servicios web necesitan autenticación y suelen disponer de un sistema de time-out para finalizar la sesión cuando ha habido un tiempo largo de espera sin actividad. Personas con discapacidad pueden necesitar más tiempo de lo normal para realizar una acción (por ejemplo rellenar un formulario), si la sesión le finaliza, sin la posibilidad de recuperar el estado en el que se estaba antes de finalizar la sesión, la persona deberá volver a empezar de nuevo, por lo que es posible que tampoco pueda finalizar la acción.

Texto alternativo no representa correctamente el texto original ya que este muestra información debido a diferencia de colores

Supongamos que tenemos una gráfica de barras en las que se muestra la población masculina y femenina según los paises de una región. Para distinguir qué datos pertenecen a uno u otro género, se muestra usando dos colores: azul hombres, rojo mujeres. El texto alternativo de esa imagen suele indicar las cantidades, pero no a qué genero pertenece.

Más información

| |

W3C: fallos de accesibilidad (II)

Seguimos con los fallos de accesibilidad que se suelen cometer en el desarrollo web, que nos ofrece la W3C y que empezamos a tratar hace unos días.

Mostrar imágenes con información importante mediante estilos

Se trata de usar una imagen que contiene información (por ejemplo para los enlaces del menú) y mostrarla como fondo de un elemento y que no haya un texto que indique el contenido de la imagen.

Una solución es escribir el texto pero no hacerlo visible, para ello usaremos la propiedad text-ident, si le damos un valor negativo elevado el texto desaparecerá por la izquierda. Por ejemplo, tenemos una imagen titulo.png que tiene el título del blog con un diseño especial, lógicamente queremos que se vea así por temas de diseño e imagen. Ahora bien, si solo mostramos la imagen, no somos capaces de leer el contenido de esta. Por ello tendremos que hacer lo siguiente para que el texto aparezca sin que haya estilos y con estilos solo aparezca la imagen:

h1 {
background: url(titulo.png);
width: 200px;
height: 100px;
text-indent: -10000px;
}
<h1>Título</h1>

Usar el estilo blink sin el mecanismo para parar el parpadeo

Esta es corta, no uses jamás text-decoration: blink. Y si por un casual no te queda otra posibilidad que usarlo, crea un script que pare el parpadeo a los 3 segundos.

Usar un applet o un flash que parpadee sin el mecanismo para pararlos

Lo mismo que el punto anterior, pero enfocado a applets y a animaciones Flash.

Usar subtítulos que omiten parte del diálogo o sonidos importantes

Si vas a ofrecer un sonido, una conversación y no muestras los subtítulos con todo el contenido (conversación y sonidos destacados), no se trata de un buen subtítulo y puede haber información importante que se escape.

Más información

| |

W3C: fallos de accesibilidad (I)

Hoy vamos a empezar una serie de artículos en los que pretendemos explicar los fallos que se cometen en accesibilidad cuando se realizan aplicaciones web y las técnicas que debemos usar para evitar estos fallos. Para ello nos basamos en lo que especifica la W3C en su WCAG 2.0 (aún en estado borrador).

Error 1: modificar el significado del contenido debido al posicionamiento mediante CSS

Se trata de cambiar el significado semántico de una etiqueta, modificando su posicionamiento mediante CSS. Por ejemplo, si queremos crearnos una lista de elementos:

  • Elemento 1
    • Elemento 1.1
    • Elemento 1.2
    • Elemento 1.3
  • Elemento 2
    • Elemento 2.1
    • Elemento 2.2


El fallo consiste en usar etiquetas no destinadas a ese sentido, cambiarle los estilos y representarlas como queremos. Por ejemplo podemos usar span para representar cada elemento y disponerlos en la posición que nos conviene:

<span class="cab1">Elemento 1</span>
<span class="cab2">Elemento 2</span>
<span class="ele1">Elemento 1.1</span>
<span class="ele2">Elemento 2.1</span>
<span class="ele3">Elemento 1.2</span>
<span class="ele4">Elemento 2.3</span>

Y con los estilos siguientes:

.cab1 {
position: absolute;
top: 0px;
left: 0px;
}
.cab2 {
position: absolute;
top: 0px;
left: 200px;
}
.ele1 {
position: absolute;
top: 20px;
left: 0px;
}
.ele2 {
position: absolute;
top: 20px;
left: 200px;
}
.ele3 {
position: absolute;
top: 40px;
left: 0px;
}
.ele4 {
position: absolute;
top: 40px;
left: 200px;
}

obtendríamos el mismo resultado visual, pero si quitaramos los estilos obtendríamos lo siguiente:

Elemento 1 Elemento 2 Elemento 1.1 Elemento 2.1 Elemento 1.2 Elemento 2.3

lo cual no tendría mucho sentido.

Error 2: modificar el aspecto del texto para mostrar algo que ya representa una etiqueta

Existen varias etiquetas de texto que tiene diferentes funcionalidades, pero aún así es típico encontrarse textos con sus estilos modificados para mostrar el resultado de una etiqueta ya existente. Un ejemplo muy común es este:

<span class="negrita">Título</span>
.negrita {
font-weight: bold;
}

Lo correcto sería usar la etiqueta strong.

Más información

Truwex Online: validador de accesibilidad y calidad

Truwex ofrece una herramienta online para comprobar la accesibilidad y la calidad de un URL dada. Una de las mayores diferencias con otras aplicaciones parecidas es que valida el código HTML generado, no solo el código HTML plano, tiene en cuenta el código generado por el Javascript.
Algo que también me ha llamado mucho la atención es que ofrece la posibilidad de ver los errores detectados en la propia página, incluso cuando se trata de capas ocultas, facilitando así la localización de los errores, y por qué no, entender qué es lo que está mal hecho.
truwex.png
En la misma página nos explican los errores que detecta y cómo solucionarlos.
También es curiosa la aplicación online que comprueba el script de Google Analytics que contiene la página.
Truwex Online
Vía / 456 Barea Street

Herramientas para crear webs accesibles

Desde Accessify nos ofrecen una serie de herramientas que nos ayudarán a crear webs más accesibles. Son wizards o herramientas sencillas pero que nos pueden facilitar mucho el trabajo.
Entre las herramientas tenemos un generador de tablas, de formularios (con o sin tablas), de pop-ups y otros más. A parte, nos ofrece una lista de aplicaciones generales, no centradas en la accesibilidad, pero que también serán de gran ayuda: generador de capas o de listados, un script para escapar código HTML para incluirlo en nuestras páginas, …

Accessibility Tools & Wizards