Uninstallme

La Web se ideó cuadrada.

Iniciar o detener Flash desde HTML con Javascript

27 de Julio 2009

Es una buena práctica, sobretodo cuando se usan vídeos o animaciones flash que contengan sonido, el dejar la reproducción de la película en manos del usuario en vez de iniciarla automáticamente.

Las veces que esto se cumple se suele hacer colocando un control en la propia película flash, como un icono de Play o similar semitransparente.

El uso exclusivo de este método puede suponer un problema para usuarios de navegadores que no sean Internet Explorer y no utilicen ratón, ya que los flashes no pueden recibir el foco mediante teclado a no ser que se activen previamente con el ratón.

Incluir además unos enlaces en HTML para iniciar o detener la reproducción de Flash supondría una pequeña mejora de accesibilidad para estos usuarios.

Los pasos que hay que seguir para conseguirlo son:

  1. Dar un ID al object que contiene el Flash
  2. Detener la reproducción automática de la animación:
    1. Si la animación está en la línea de tiempo principal basta con usar el parámetro play con el valor false en el HTML
    2. Si la animación está en otra línea de tiempo tendremos que detenerla en el propio flash mediante un nombreDeInstancia.stop() en la línea de tiempo principal.
  3. Asignar la función de iniciar / detener a los enlaces correspondientes en HTML

Ejemplos de los dos casos

Object película Flash con animación en la línea de tiempo principal

HTML del flash


<object width="155" height="17" id="ejemplo-1" type="application/x-shockwave-flash" data="ejemplo.swf">
    <param name="src" value="ejemplo.swf" />
    <param name="play" value="false" />
</object>

Controles HTML (lo ideal para una degradación elegante sería pintarlos con Javascript, ya que sólo con Javascript habilitado pueden funcionar)


<ul id="controles-1">
    <li><a href="#">Iniciar reproducción</a></li>
    <li><a href="#">Pausar reproducción</a></li>
</ul>

Javascript


var control1 = document.getElementById('controles-1').getElementsByTagName('a');
control1[0].onclick = function(){
    document.getElementById('ejemplo-1').Play();
    return false;
}
control1[1].onclick = function(){
    document.getElementById('ejemplo-1').StopPlay();
    return false;
}

Demo

Object película Flash con animación en una línea de tiempo distinta a la principal

HTML del flash


<object width="165" height="48" id="ejemplo-2" type="application/x-shockwave-flash" data="ejemplo-2.swf">
    <param name="src" value="ejemplo-2.swf" />
</object>

Javascript

En este caso, para iniciar o detener la animación tendremos que usar los métodos TPlay("ruta_a_linea_tiempo") y TStopPlay("ruta_a_linea_tiempo")


var control2 = document.getElementById('controles-2').getElementsByTagName('a');
control2[0].onclick = function(){
    document.getElementById('ejemplo-2').TPlay("_root/mc_barra");
    return false;
}
control2[1].onclick = function(){
document.getElementById('ejemplo-2').TStopPlay("_root/mc_barra");
    return false;
}

Demo

Existen otros métodos predefinidos útiles para controlar la reproducción de una película Flash, como Rewind() o GotoFrame()

Aprovecho este post para recomendar un par de recursos que pueden sernos de gran utilidad a la hora de mejorar la accesibilidad de vídeo Flash (ya que por la página de recursos no se pasa ni GOOGLE):

JW Player Controls
Reproductor de Flash Vídeo que permite controlar la reproducción mediante teclado, añadir subtítulos y descripciónes de audio y además añade los atributos apropiados ARIA. Utiliza JW FLV Player junto con un plugin de accesibilidad. Los controles javascript se proporcionan mediante la librería Dojo.
Ejemplos de control del reproductor JW Player mediante Javascript
Varios ejemplos de control de la reproducción de contenido multimedia mediante Javascript usando JW Player.

Más información

Archivado en Accesibilidad, HTML, Javascript, flash

2 Comentarios

Evitar el espacio extra entre elementos de lista en línea

15 de Abril 2009

Caso típico: lista centrada de enlaces al pie de página separados por barras u otro elemento.

Enlaces centrados en el pie de página

Enlaces centrados en el pie de página

Para que la lista aparezca centrada necesitamos que los elementos de lista se muestren en línea en vez de en bloque.


ul{text-align: center;}
li{display: inline; padding: 0 6px 0 5px; background: url(../img/separador.gif) 100% 50% no-repeat;}

Problema típico: la separación entre ítems no es igual en distintos navegadores, básicamente, entre Explorer y el resto.

Distinta separación entre elementos de lista en Explorer

Distinta separación entre elementos de lista en Explorer

Solución (muy vieja): evitar la separación (saltos de línea) entre los elementos de lista en el HTML.


<ul><li><a href="#">Lorem ipsum</a></li><li><a href="#">Sit amet</a></li><li><a href="#">Consectetuer</a></li></ul>

Se puede mejorar un poco la legibilidad del código y evitar tener toda la lista en una línea de esta forma:


<ul><li
><a href="#">Lorem ipsum</a></li
><li><a href="#">Sit amet</a></li
><li><a href="#">Consectetuer</a></li
></ul>

El resultado de usar esta técnica:

Misma separación entre elementos de lista en todos los navegadores

Misma separación entre elementos de lista en todos los navegadores

Demo.

Visto en CSS:Inline list, entre otras cosas muuuy interesantes.

Archivado en CSS, HTML

2 Comentarios

El debate del H1

8 de Febrero 2009

Si no teníamos suficiente con el típico debate sobre usar uno o varios encabezados de primer nivel, ahora tenemos otro para la colección: ¿H1 para el título principal de la página o para el logo del sitio?

La cosa llega al extremo de tener su propia web, en la que podemos ver los argumentos y votos dados a través de Twitter (me temo que nunca participaré.)

De momento va ganando la opinión de usar H1 para el título principal de la página. Yo comienzo a pensar que da un poco igual mientras se hayan hecho otras cosas bien, como usar un título (elemento <title>) descriptivo y una jerarquía de encabezados con sentido.

Archivado en Accesibilidad, Cajón de sastre, HTML

3 Comentarios

Crear documentos XHTML válidos usando atributos desaprobados

8 de Febrero 2009

En muchas ocasiones nos habrá tocado encontrarnos con la necesidad de usar atributos desaprobados por el W3C, que hacen que nuestros documentos no validen. Este es el caso del atributo autocomplete en campos de formulario, el atributo target para enlaces en XHTML estricto o los atributos de WAI-ARIA.

Podemos solucionar el problema de la validación mediante el uso de una DTD personalizada. Reciéntemente han sido varios los sitios que han propuesto el uso de una DTD personalizada para validar documentos que usan atributos de WAI-ARIA. En todos estos casos se usaba una DTD externa. Para usar una DTD externa sólo necesitamos descargar una DTD original de XHTML y modificarla añadiendo los atributos que deseemos para determinados elementos. Después necesitaremos hacer referencia a esta DTD, alojada en un dominio público, en el DOCTYPE del documento HTML.

Ejemplo:


<!DOCTYPE html SYSTEM
"http://dominio.com/dtd/xhtml1-custom.dtd">

Existe otra opción que consiste en modificar una DTD de forma interna, en el propio documento XHTML, sin necesidad de necesitar un documento DTD alojado en el servidor.

En el siguiente ejemplo modificamos la dtd de XHTMl transicional, para añadir el atributo autocomplete a elementos input:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
[
<!ATTLIST input autocomplete (off) #IMPLIED>
]
>

En esta línea <!ATTLIST input autocomplete (off) #IMPLIED> estamos diciendo que al elemento input se le añade un nuevo atributo (autocomplete), cuyo valor será off. #IMPLIED indica que su uso es opcional.

De la misma forma podríamos añadir el atributo target para los enlaces en XHTML estricto. Por cierto, una práctica nada recomendable.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ATTLIST a target (_blank|_parent|_search|_self|_top) #IMPLIED>
]
>

Y añadir atributos WAI-ARIA a determinados elementos HTML sin necesidad de usar Javascript. En este caso añadimos el atributo aria-required con el valor true para elementos input.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ATTLIST input aria-required (true) #IMPLIED>
]
>

Esta técnica tiene un pequeño problema, y es que, en el navegador nos aparecen unos caracteres al principio del documento ]>
En este ejemplo, que usa XTHML estricto e incluye la ampliación del DTD para admitir, tanto el atributo autocomplete, como el atributo target en enlaces y aria-required en elementos input, se puede ver el problema de los caracteres al principio del documento.

¿Cómo podemos solucionarlo?

La solución elegante consiste simplemente en servir el documento como application/xhtml+xml, con la extensión .xhtml. El problema de este método es que Internet Explorer no acepta este Content-type e intentará guardar el documento. Ver ejemplo de XHTML servido como application/xhtml+xml.

La solución sucia pero eficaz, consiste en utilizar CSS para ocultar los caracteres no deseados. Podemos hacerlo de varias formas, esta es la que yo he elegido después de varias opciones:


html{text-indent: -99999em; line-height: 0;}
body *{text-indent: 0; line-height: normal;}

Ver ejemplo de XHTML estricto servido como text/html (aceptado por Internet Explorer) con los estilos anteriores.

Mi opinión sobre todo esto

La verdad es que lo he publicado como una opción a tener en cuenta en casos extremos (el plan B), y me parece, más que nada, una forma de engañar a los validadores, que se debería usar con moderación y en ocasiones muy puntuales. En los ejemplos expuestos se han usado atributos de uso común, pero sería peligroso que cada uno decidiera usar atributos de su propia cosecha. Recomiendo echarle un vistazo a lo que opina el W3C sobre las DTD personalizadas, simplemente “no utilice DTDs personalizadas“.

Más información

Validating a Custom DTD (A List Apart)

Archivado en HTML

Comentar

Doble uso del atributo ABBR en encabezados de tabla

7 de Diciembre 2008

Si queremos (deberíamos) hacer una tabla accesible, podemos hacer uso del atributo abbr de los encabezados de tabla (<TH>). Este atributo puede servir a dos propósitos complétamente distintos.

Abreviar contenidos largos en celdas

Muchas veces, se piensa que el uso de este atributo cumple la misma función que la etiqueta <abbr> de HTML para mostrar la forma extendidida de una abreviatura o abreviación, sin embargo, su uso en encabezados de tabla, aunque también puede cumplir este objetivo, está concebido justamente para el contrario. En la traducción de la especificación de HTML 4.01 de html.conclase.net, podemos encontrar el siguiente fragmento:

Este atributo debería usarse para proporcionar una forma abreviada del contenido de la celda; los agentes de usuario pueden representar esta forma abreviada en lugar del contenido de la celda cuando sea apropiado. Los nombres abreviados deberían ser cortos, ya que los agentes de usuario pueden representarlos repetidas veces. Por ejemplo, los sintetizadores de voz pueden representar los encabezados abreviados relacionados con una celda en particular antes de representar el contenido de esa celda.

En este ejemplo de código extraído de 456 Berea Street, podemos ver cómo se ha usado el atributo abbr para proporcionar una forma abreviada de cada encabezado:


<table summary="The number of employees and the foundation year of some imaginary companies.">
    <caption>Table 1: Company data</caption>
        <tr>
            <th abbr="Company">Company Name</th>
            <th abbr="Employees">Number of Employees</th>
            <th abbr="Founded">Foundation Year</th>
    </tr>

Expandir formas abreviadas en celdas

Otro caso en el que necesitaremos usarlo, es cuando el encabezado de tabla ya está abreviado. Un ejemplo podría ser el de los días de la semana abreviados mediate sus iniciales (L, M, X, J, V, S, D), en el que el uso del atributo abbr serviría para mostrar la forma extendida (Lunes, Martes, etc.)

En este ejemplo extraído de Dive Into Accessibility, podemos ver este otro uso del atributo abbr:


<tr>
    <th abbr="Sunday" align="center"><span class="calendar">Sun</span></th>
    <th abbr="Monday" align="center"><span class="calendar">Mon</span></th>
    <th abbr="Tuesday" align="center"><span class="calendar">Tue</span></th>
    <th abbr="Wednesday" align="center"><span class="calendar">Wed</span></th>
    [...]
</tr>

En mi opinión, raras veces necesitaremos usar este atributo, a no ser que tengamos un encabezado de tabla muy largo y su repetición continua pueda resultar una molestia.

Cuando lo usemos con el propósito contrario (mostrar una forma extendida), deberemos asegurarnos de que es realmente necesario y no estamos causando una molestia proporcionando una forma larga para un encabezado abreviado, si este ya resulta suficiéntemente claro por sí mismo.

Archivado en Accesibilidad, HTML, Marcado semántico

Comentar

Encabezados ocultos: ¿una mejora de accesibilidad o un obstáculo?

17 de Noviembre 2008

He estado haciendo cambios en el tema actual de este blog y después de darle unas cuantas vueltas y probar yo misma a navegar algunas páginas y otras webs usando un lector de pantalla, he tomado la decisión drástica de cargarme la mayoría de los encabezados ocultos que estaba usando.

La razón: encabezados que me indiquen qué es el contenido principal, la navegación o el buscador, no me ofrecen ninguna mejora ni son realmente necesarios para acceder al contenido que me interesa.

Una de las pautas para la accesibilidad del contenido web nos dice que usemos encabezados para transmitir la estructura del documento.

Aunque es cierto que nuestro HTML no puede por sí mismo ofrecer información sobre la estructura del documento en cuanto a áreas o secciones de este como la navegación o el contenido principal, probablemente los desarrolladores hemos hecho una interpretación incorrecta de esta pauta, al utilizar encabezados ocultos para marcar estas secciones con la intención de ofrecer una mejora de accesibilidad para usuarios de lectores de pantalla.

El problema es que como desarrolladores, queremos que la estructura de nuestra página sea perféctamente presentada a usuarios de lectores de pantalla y olvidamos que muy probablemente, a estos usuarios les importe más bien poco esta estructura y, al igual que cualquier usuario, busquen con las mismas “prisas”, el contenido que les interesa saltando a través de encabezados o enlaces (de ahí que el texto de los enlaces deba tener sentido por sí mismo, fuera de contexto). Es entonces cuando encontrar un encabezado que me diga “Contenido” me ayuda más bien poco, cuando yo lo que estoy buscando es algo que me diga claramente “de qué va esto”. Es posible incluso que la información sobre el contenido que deberían aportar los encabezados, se pierda en favor de la información sobre la estructura de la página, y aquí es cuando en vez de una mejora hemos conseguido todo lo contrario.

Hemos utilizado encabezados ocultos para transmitir, no información sobre el contenido, sino metainformación sobre este, y esta es una labor que no debería corresponder a los encabezados HTML, sino a otras etiquetas o atributos concebidos precísamente para este fin.

La realidad es que HTML no dispone de esas etiquetas, que veremos (algún día) en HTML 5. Aunque habrá casos en los que siga siendo necesario el uso de encabezados ocultos, sobretodo cuando no estén contemplados en el diseño pero sean necesarios para entender el contenido al que preceden, en la mayoría de casos, el encabezado natural debería ser suficiente.

WAI-ARIA ofrece la posibilidad de marcar estas áreas del documento (document landmark roles) mediante distintos valores para el atributo role, como main para el contenido principal, article para una porción de contenido independiente o contentinfo para los típicos enlaces a política de privacidad, nota de copyright, etc. En un futuro, las ayudas técnicas podrán proporcionar atajos de teclado u otros mecanismos para acceder diréctamente a cada una de estas áreas, lo que hoy hacemos mediante anclas (skip links). La realidad es que a día de hoy, sin tener en cuenta el soporte nulo de WAI-ARIA por las versiones actuales de Internet Explorer (6 y 7), los lectores de pantalla más populares, como JAWS, NVDA o Window Eyes, no soportan esta característica. Sólo JAWS 10 Beta tiene soporte para document landmark roles. Agradecería que me corrijan si me estoy equivocando.

En cualquier caso, no perdemos nada por usar estos landmark roles en nuestro HTML. Algunas extensiones para Firefox, como Juicy Studio Accessibility Toolbar o la Firefox Accessibility Extension, ofrecen esta información cuando existe. Siendo un poco optimistas, podemos pensar que no son utilizadas solamente por desarrolladores web.

Archivado en Accesibilidad, HTML

Comentar

¿Marcado semántico o estructural?

25 de Octubre 2008

Acabo de encontrar un interesante hilo en la lista de correo de Ovillo sobre el uso de los términos “marcado semántico” frente a “marcado estructural”.

Sincéramente es un tema que me revienta, ya que se está hablando de cosas distintas y mezclando la velocidad con el tocino por la tendencia de sacar a relucir Web Semántica a la mínima oportunidad.

Continúa en "¿Marcado semántico o estructural?"

Archivado en HTML, Haciendo amigos, Marcado semántico

1 Comentario

Alternativas al uso de autocomplete en formularios

29 de Julio 2008

El autocompletado de formularios es una característica de los navegadores que permite guardar datos introducidos en formularios para facilitar el posterior rellenado automático. Aunque esta opción puede ser desactivada desde las preferencias del navegador y en el momento de enviar un formulario aparece un cuadro de diálogo preguntando si se desean guardar los datos introducidos, hay casos en los que se hace necesario impedir que el navegador almacene estos datos por razones de seguridad. Esto ocurre normalmente en webs de entidades bancarias.

Continúa en "Alternativas al uso de autocomplete en formularios"

Archivado en HTML, Javascript, Seguridad

1 Comentario