accesskey_mod_content

Imágenes, multimedia y CAPTCHA

Para cada imagen compleja se debe proporcionar una descripción detallada en un documento HTML aparte o en el mismo en el que se encuentra dicha imagen.

En HTML 4.01 o XHTML la URL de esta descripción detallada se indicará en el atributo longdesc de la imagen. Adicionalmente, y para ofrecer la máxima compatibilidad, se puede proporcionar un enlace de texto a continuación de la imagen, vinculándolo al comienzo de la descripción detallada. Aún así, sigue siendo necesario ofrecer para cada imagen una alternativa textual en el atributo alt que identifique brevemente el tipo de información transmitida a través del mismo.

Ejemplo de código

<img alt="Texto identificativo de la imagen compleja" longdesc="descripción_larga.html" src="Dirección de la imagen" />
<p><a href="descripción_larga.html">Descripción de [nombre de la imagen]</a></p>

En cambio, en HTML5 el atributo longdesc pasa a considerarse como obsoleto. En este caso, la forma de incluir una descripción detallada es incluyendo dicha descripción en la misma página o en una página aparte enlazada con un enlace situado de forma contigua a la imagen.

Como imagen decorativa se entiende toda aquella que no transmite ninguna información relevante y no posee funcionalidad alguna. Pensando en una página Web concreta, esto significaría que al carecer de estas imágenes no se pierde ninguna información.

Como imagen no decorativa, se puede entender, que son todas aquellas que complementan de alguna manera la información mostrada y/o transmiten información por sí mismas. Asimismo, las imágenes funcionales no se consideran decorativas (enlaces, banners, etc.)

Un elemento de vídeo para que sea accesible de cumplir los siguientes puntos:

  • Poseer una alternativa accesible: Para cualquier elemento de video es necesario proporcionar una alternativa equivalente tanto para la banda visual como para la sonora, es decir, una transcripción completa de toda la información transmitida en el vídeo. Además, dicha alternativa se debe encontrar en un formato accesible.
  • Sincronizar los equivalentes alternativos con el propio vídeo: Independientemente de que las presentaciones multimedia posean un equivalente textual, se debe proporcionar un equivalente sincronizado (subtítulos) de la banda sonora.
  • Proporcionar una descripción sonora de la información importante de la pista visual: Cuando se trasmita información importante en la banda visual del vídeo, es necesario incluir una descripción sonora de la escena (también llamada Audiodescripción).
  • Destellos y parpadeos apropiados: Se debe evitar que los contenidos de los elementos de vídeo produzcan parpadeos y destellos.
  • Control de la reproducción: Es también importante proporcionar a los elementos de vídeo, un mecanismo mediante el cual se permita controlar a los usuarios la reproducción de los mismos (avance, pausa, etc.). Además, este mecanismo, se deberá poder manejar desde cualquier tipo de de dispositivo (teclado, ratón, etc.)

En caso de que el contenido multimedia se emita en directo el único requisito es que se proporcionen subtítulos en tiempo real, además de evitar que se produzcan destellos y parpadeos. No es necesario proporcionar una transcripción textual completa ni descripción sonora. Aún así, para facilitar el acceso a dicho contenido se recomienda proporcionar a posteriori una versión grabada con todas las medidas de accesibilidad necesarias.

Para ampliar información sobre los vídeos se puede consultar la “Guía de Accesibilidad para Contenido Multimedia” disponible en el apartado "Guías Prácticas" del área de documentación .

Cualquier objeto Flash debe estar diseñado en base a los criterios comunes de accesibilidad: uso adecuado del color, independencia de dispositivo, navegación coherente, lenguaje claro y sencillo, control de detección del movimiento, no empleo de de destellos y en general, todos aquellos aspectos recogidos en las WCAG que pudieran ser aplicados sobre la interfaz y funcionalidad de este tipo de contenidos. Deben emplearse técnicas y herramientas como el panel de accesibilidad (incorporado desde la versión 6.0 y mejorado en las versiones sucesivas) del software de desarrollo de Adobe Flash. Los elementos de interacción del objeto deben permitir una tabulación ordenada (acorde con la disposición en pantalla) y cualquier información importante del objeto debe ser interpretada adecuadamente por un lector de pantalla.

Al mismo tiempo, y debido a que no desde todos los agentes de usuario podrá accederse de forma completa a este tipo de objetos (por incompatibilidades con el motor MSAA (Microsoft Active Accessibility), debe proporcionarse una alternativa equivalente en (x)HTML+CSS. Dicha alternativa deberá incluirse entre las etiquetas OBJECT del Flash, y complementariamente contextualizada en el propio documento (acompañando al objeto pero independiente de éste) o en un vínculo a un documento independiente.

Si el objeto Flash es meramente decorativo (no ofrece información textual, no ofrece funcionalidad y sólo se emplea como acompañamiento visual) no es necesario proporcionar alternativa al mismo.

Independientemente de si el objeto Flash es decorativo o si dispone de una alternativa accesible, éste no debe interferir o dificultar el acceso al resto de contenidos de la página a las personas con discapacidad. Así, no podrá tener destellos que puedan provocar ataques a personas con epilepsia fotosensitiva, no podrá bloquear o interrumplir la navegación con teclado por el resto de contenidos y deberá disponer de mecanismos para controlar la reproducción del audio y pausar o detener los movimientos y animaciones.

Por último, para incrustar un elemento Flash en un documento, es recomendable emplear un código (X)HTML válido según las gramáticas publicadas por W3C: es común el empleo de atributos y elementos desaconsejados como EMBED, generados por la propia herramienta de desarrollo. En su lugar, debería emplearse un código igualmente funcional y tolerante con las gramáticas W3C.

Ejemplo de código 

 

<object      data="flash.swf"       type="application/x-shockwave-flash"    width="1000" height="680" id="flash">
<param name="allowScriptAccess" value="sameDomain" />
<param name="allowFullScreen" value="false" />
<param name="movie" value="flash.swf" />
<param name="quality" value="high" />
<param name="bgcolor" value="#ffffff" />
     <p class="noflash"> 
        <a href=”version_html”> Alternativa equivalente </a>
     </p>
 

 

La evolución de las técnicas CAPTCHA ha puesto de manifiesto que las soluciones tradicionales, como los caracteres contenidos en imágenes, no solo son inseguros, si no que también dificultan la interacción con personas con algún tipo de discapacidad. En la actualidad, desarrollos recientes como Google reCAPTCHA, la autenticación multidispositivo y sistemas de federación de identidades constituyen la mejor forma de distinguir a un humano de una máquina.

No obstante, aunque hay algunas soluciones CAPTCHA mejor que otras, no existe aún la solución ideal. Lo que sí es importante es que el CAPTCHA incluido en el sitio web sea capaz de identificar correctamente a personas con discapacidades como humanos.

El grupo de trabajo de Accessible Platform Architectures (APA)(Abre en nueva ventana) , con la colaboración de Research Questions Task Force (RQTF)(Abre en nueva ventana) , ha elaborado el borrador " Inaccessibility of CAPTCHA(Abre en nueva ventana) ". Esta publicación data del 2005, aunque está siendo continuamente revisada con el objetivo de incluir los últimos cambios tecnológicos en la materia.

En este documento se analizan los distintos enfoques de CAPTCHA existentes, junto con sus barreras de accesibilidad asociadas. También se incluyen referencias a las investigaciones más recientes sobre esta temática, además de abordar los sistemas de federación de identidades, autenticación de doble factor, biométrica, CAPTCHA 3D, etc.

Este documento sirve de ayuda para dar cumplimiento a los requisitos recogidos en el criterio 1.1.1 Contenido no textual de las WCAG 2.0 y 2.1.

Punto de Acceso General
Punto de Acceso General