Uninstallme

Desarrollo front-end, estándares web, accesibilidad y más

Cuestionando los diseños elásticos

Por kcmr, el 17 de julio de 2010 en Accesibilidad, CSS, Usabilidad

Until user agents…

Quienes suelan consultar las WCAG (Web Content Accessibility Guidelines), tendrán esta frase grabada en la memoria: Hasta que los agentes de usuario permitan…. Pues bien, estoy segura de que con la lenta agonía de Explorer 6, muchos nos habremos preguntado hasta qué punto tiene sentido seguir utilizando unidades relativas para los tamaños de fuente, ya que el resto de navegadores no tiene problemas para escalar fuentes cuando su tamaño ha sido expresado en píxeles. ¿Correcto? Pues no.

Internet Explorer no escala las fuentes en píxeles

Hace relativamente poco tiempo descubrí algo que desconocía por completo: ninguna versión de Internet Explorer escala las fuentes cuyo tamaño ha sido expresado en píxeles:

Es fácil no darse cuenta de este detalle porque cuando utilizamos la combinación de teclas Ctrl + o Ctrl – en Explorer (versiones superiores a la 6), activamos el zoom de página con resultados aparentemente similares a los que obtendríamos aumentando el tamaño de fuente, por lo tanto, sigue teniendo sentido utilizar unidades relativas para los tamaños de fuente.

Zoom de página y escalado de texto

Ahora bien, ¿hasta qué punto es correcto utilizar unidades relativas para todo? La mayoría de navegadores actuales, <ironia>excepto Explorer 6</ironia>, nos proporcionan inteligentemente dos formas de zoom: zoom de página completa o ampliar sólo texto.

Escalado de texto en Firefox

Escalado de texto en Firefox

Google Chrome y Opera sólo proporcionan zoom de página completa. Parece que a algunos usuarios de Chrome están algo descontentos: Need a text-only Zoom.

Teniendo en cuenta que la resolución mayoritaria, en portátiles y ordenadores de sobremesa, sigue siendo de 1024, y que las páginas se diseñan para esta resolución, en el momento en que hacemos zoom de página completa aparecen las molestas barras de scroll horizontales.

Si nuestro diseño es elástico, es decir, los tamaños de bloques contenedores se expresan en emes, estamos rompiendo la capacidad del navegador de ampliar sólo texto o hacer zoom de página, ya que al ampliar sólo texto aumentarán también los tamaños de bloques con las consecuentes barras de scroll horizontales, y si hay algo cierto, es que a nadie le gusta el scroll horizontal.

“Low-vision users don’t like horizontal scrolling.” I’ve not done extensive research in this area myself, so it’s hard to counter-argue. Besides, it’s safe to say nobody — good vision or not — likes horizontal scrolling.

We found during usability testing for a site with a large proportion of users with vision problems that most of them preferred to use text zoom instead of page zoom because page zoom almost always means horizontal scrolling.

¿La mejor elección de diseño?

Quizá el diseño perfecto sea el híbrido líquido-elástico (vaya nombrecito), pero es difícil de llevar a cabo y no está libre de problemas. Opera y Webkit (Safari / Google Chrome) comparten un bug: ignoran los decimales en porcentajes. (Demo del bug). Explorer tampoco se lleva especialmente bien con los porcentajes.

CSS 3 nos brinda nuevas posibilidades que nos permiten adaptar el diseño en función de la resolución de pantalla, las Media Queries, opción que podemos usar ya para los navegadores que pueden beneficiarse de ello, especialmente para iPhone y otros dispositivos móviles.

Mi elección

Personalmente, llevo una temporada utilizando la opción de expresar los tamaños de bloques en píxeles y los de fuentes en emes, siendo consciente de que el uso de píxeles está penalizadísimo, tanto por revisores automáticos de accesibilidad como humanos, e incluso diría que mal visto entre maquetadores, pero las “normas” siempre hay que cuestionárselas para llegar a mejoras. Como ejemplo, muchas de las pautas que se cuestionaban de las WCAG 1 en las Samuray Errata, se han modificado en las WCAG 2.

Qué dicen las WCAG

En las WCAG no se dicta una opción concreta a utilizar en cuanto a tipo de diseño, simplemente se ofrecen unas pautas y una serie de técnicas para ayudarnos a conseguirlas. Algunas de estas técnicas:

Using percentage values in CSS for container size

The objective of this technique is to make it possible for users who need to increase the size of text in order to read it will not have to scroll horizontally in order to read a line of text.

Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized

The purpose of this technique is to ensure that CSS is used in a way that allows users to view content in such a way that line length can average 80 characters or less. [...] This technique also allows for column width to grow wider as font sizes increase, which will reduce the possibility of clipping as the text size increases..

En ningún momento se propone la técnica de usar unidades absolutas para contenedores, sino más bien todo lo contrario. Si no me equivoco, tampoco se prohibe o desaconseja expresamente el uso de píxeles para contenedores, simplemente se insiste en que el texto pueda escalarse sin que aparezca cortado y a ser posible, sin que sea necesario utilizar el scroll horizontal para leer una línea completa.

Conclusión

Ahí están los problemas de los diseños elásticos y algunas de las recomendaciones para cumplir con las pautas de accesibilidad para que cada uno elija la opción más apropiada, teniendo siempre en cuenta el púbico objetivo de una web y las capacidades de los navegadores más usados en cada momento.

Más información

2 Comentarios

El uso del pseudoprotocolo (href="javascript:nombreFuncion();") en enlaces es una mala práctica de acuerdo con las normas del Javascript no intrusivo. Los enlaces deben tener una url válida que funcione sin Javascript. Por ejemplo, un enlace que abre una popup debe tener una url en su atributo href, de manera que sin Javascript siga siendo un enlace válido.

Pero no todos los enlaces que ejecutan alguna función Javascript tienen que tener una url en su atributo href. Algunos sirven para realizar acciones dentro de la propia página, como puede ser mostrar / ocultar una capa, pasar a la imagen siguiente en un carrusel, etc.

En estos casos, lo correcto es crear esos enlaces con Javascript, ya que sólo con Javascript habilitado tienen sentido (no deben estar previamente en el código HTML), y asignarles como atributo href una almohadilla (#) o dejarlo vacío.

En algún blog que no consigo encontrar proponían usar para este tipo de enlaces el pseudoprotocolo javascript: u otro que consideremos más apropiado (inventado), como podría ser imagen:.

De esta forma, estos enlaces proporcionan información acerca de su función al hacer rollover sobre ellos o cuando tienen el foco. Esta información suele aparecer en la barra de estado del navegador. También es útil para usuarios de lectores de pantalla que puedan tenerlos configurados para no leer el atributo title.

Atributo href del enlace mostrado en la barra de estado de Firefox

Atributo href del enlace mostrado en la barra de estado de Firefox

Habrá quien se preguntará si es correcto asignar este tipo de funciones a enlaces en lugar de a otros elementos HTML. La respuesta es que sí, ya que los enlaces pueden tener de forma natural el foco y ser activados cuando se utiliza el teclado para navegar y moverse por la página.

Sin comentarios

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

3 Comentarios

El uso de iconos de banderas para la elección de idioma en un sitio web plantea una serie de problemas, tanto de usabilidad como de accesibilidad, que no lo hacen recomendable. Si buscamos un poquito en Internet y le damos un par de vueltas podemos ver que no es una buena idea y sin embargo, su uso es tan frecuente que es fácil caer en este error de diseño.

Algunos problemas del uso de banderas

Usar sólo iconos de bandera (sin texto)

Como dice Roger Johansson en Indicating language choice: flags, text, both, neither?, usar sólo una bandera es un big no-no! (Me gusta esta expresión!)

Anteriormente comenté en este blog los problemas de usar sólo iconos como enlaces, llegando a la conclusión de que los iconos siempre deberían ir acompañados de un enlace textual, o mejor dicho, ser un complemento de este y no el elemento que transmita la mayor parte de la información.

Poniéndonos en el caso de las banderas, ¿qué ocurre si un usuario es daltónico y confunde los colores de una bandera o si simplemente desconoce a qué país representa una bandera o incluso qué idioma se habla en determinado país? Y no hace falta irse a pensar en usuarios con discapacidades de ningún tipo, simplemente en la cantidad de países cuya bandera usa tres bandas de color rojo, azul y blanco.

Como decía Johansson, a big no-no!

Icono de bandera acompañada del nombre del idioma en ese mismo idioma

Esta opción es algo mejor que la anterior pero sigue planteando problemas, como por ejemplo, el de que algunos usuarios se puedan sentir ofendidos. ¿Le agrada a un estadounidense ver su idioma representado con la bandera de inglaterra o viceversa? Pues como comentan en You should never use flags for language choice, parece ser que a algunos no.

Hmm, I DO speak English, but this is not the flag of my country. I hate when I see this!

Por si estas razones no son suficientes, tenemos un documento del W3C Working Group que sin más rodeos dice “Do not use flag icons to indicate languages.” y nos da una razón indiscutible para ello: Las banderas representan países, no idiomas.

Posibles alternativas al uso de banderas

Usar sólo texto en el idioma correspondiente

Una opción simple y sencilla que no deja lugar a dudas y no ofende a nadie, pero que tiene el inconveniente de no ser tan fácilmente localizable y reconocible como los enlaces acompañados de icono.

Un select con los idiomas disponibles

Esta opción es buena cuando hay bastantes idiomas, pero tampoco está libre de problemas. ¿Qué etiqueta usamos para el label del select? Si usamos “idioma”, ¿en qué idioma lo ponemos?
Si decidimos prescindir del label, ¿qué ponemos como opción por defecto para el select? ¿”Seleccione idioma”?

Podemos recurrir al uso de un icono como el globo del mundo o algo similar que preceda al select, pero volvemos al problema de usar sólo iconos para transmitir información. Además esto require un esfuerzo extra de interpretación.

Conclusión

Vistos los problemas y las posibles alternativas (seguro que hay más), quizá la mejor opción sea la de usar sólo texto en el idioma correspondiente (Español | English | Français) y si a pesar de todo uno se decanta por el uso de banderas, acompañarlas siempre de texto.

Más información

8 Comentarios

Acabo de descubrir varios script que hacen posible, tanto la navegación “normal” mediante el botón volver del navegador, como el añadir páginas a los favoritos o marcadores en aplicaciones AJAX. Una solución a dos de los grandes problemas de usabilidad que presentan este tipo de aplicaciones.

Dejo cuatro enlaces rápidos:

  1. HistoryManager. Funciona con Mootools.
    It solves the typical “Back-Button” and “Ajax Bookmarks” problems for accessible browsing and a better usability in Rich Internet applications.
  2. Versión de HistoryManager para Prototype.
  3. History Keeper. No utiliza ninguna librería.
  4. UpdateControls: UpdateHistory and AnimatedUpdatePanel. Para ASP.NET AJAX.

Sin comentarios

Yo también me he sumado a esta iniciativa de dejar la web en pelotas, que pretende promover el correcto uso de Estándares Web y marcado semántico. Es el CSS Naked Day.

Me tengo que decir eso de “bueno, un día es un día” para tener la conciencia más tranquila, ya que aunque todo permanece perfectamente utilizable y comprensible sin estilos, la verdad sea dicha… resulta bastante incómodo de leer.

Una buena forma de superarlo, sobretodo cuando tenemos verdadero interés en leer algo, cosa que debe de ocurrir sólo durante un 5% del tiempo en que navegamos, es utilizar un bookmarket que aplica los estilos necesarios para mejorar la legibilidad a la parte de la página que contiene el contenido relevante, ocultando todos los demás elementos que pueden distraer la lectura, como banners, menús de navegación, etc. Se trata de Readability. En su web podemos elegir el estilo que más nos gusta entre varias opciones y una vez configurado, añadir el marcador al navegador.

Es un bookmarklet bastante útil y cómodo, no sólo para superar el día de hoy, sino para cuando nos encontramos con un tamaño de texto diminuto o longitud excesiva de líneas, dos cosas que dificultan y hacen poco apetecible la lectura.

2 Comentarios

Sí Flash ya es de por sí bastante problemático en cuanto a accesibilidad se refiere, en Firefox tiene una dificultad añadida: no se puede acceder a su contenido mediante teclado. Para navegar por los elementos de un flash en Firefox necesitamos clicar el flash. Una vez que hemos entrado ya no podemos salir usando el teclado, la tabulación queda atrapada en el flash. La buena noticia es que si hemos podido entrar en el flash, se supone que sólo hemos podido hacerlo mediante ratón, por lo que también se supone que también podremos salir del flash usando el ratón, a no ser que justamente decida fallar en ese preciso momento. En cualquier caso, este comportamiento de Flash en Firefox hace que sea dependiente de dispositivo.

No ocurre lo mismo en Internet Explorer, en el que sí podemos entrar y salir del Flash mediante teclado. Podemos imitar el comportamiento de Flash en Internet Explorer mediante Javascript y Actionscript. En el siguiente ejemplo tenemos un flash al que podemos acceder mediante teclado en Firefox, navegar por sus elementos y salir de él.

Para conseguir esto se han seguido los siguientes pasos:

  1. Dar un tabindex con valor 0 al object que contiene el flash.De esta manera conseguimos que pueda tener el foco en Firefox. El valor 0 permite que el objeto permanezca en el orden de tabulación en que aparece en la página, es decir, no se altera el orden de navegación de otros elementos. Debemos hacerlo mediante Javascript, porque sin él, podríamos entrar mediante teclado al flash pero no podríamos salir.
  2. Permitir la comunicación del Flash con Javascript.Para esto usamos el parámetro allowscriptaccess de Flash
    
    <param name="allowScriptAccess" value="always" />
    
  3. Desde Flash llamamos a la función Javascript encargada de establecer el tabindex, de esta manera, sólo si hay flash se establecerá un tabindex para el object.
  4. Añadimos para el primer y último elemento navegables del flash una función para el evento onblur (en actionscript llamado onKillFocus) encargada de llamar a la función Javascript que desenfoca el object.
    
    // primer elemento navegable
    bot_1.onKillFocus = function(newFocus){
       if(newFocus == bot_3){
          ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test');
       }
    }
    // último elemento navegable
    bot_3.onKillFocus = function(newFocus){
       if(newFocus != bot_2){
          ExternalInterface.call('AccesibleFlash.desenfocaObject', 'test');
       }
    }
    
  5. Por último, para evitar el “click para activar” en Explorer, se ha usado el método de publicación dinámica del SWFObject.

Descargar todos los archivos del ejemplo, incluido el .fla, en formato .zip

Una buena parte del “cómo conseguirlo” surgió de una cabeza inquieta de mi antiguo curro y creo, que hasta aquí puedo y debo leer.

1 Comentario

El debate del H1

Por kcmr, el 8 de febrero de 2009 en Accesibilidad, Cajón de sastre, HTML

Etiquetas: ,

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.

3 Comentarios

Hace cosa de un mes, WebAIM comenzaba a hacer una encuesta sobre el uso de lectores de pantalla, con el objetivo de mostrar las preferencias de usuarios reales y dar un poco de luz a los desarrolladores que normalmente nos basamos en suposiciones a la hora de intentar proporcionar páginas accesibles para este tipo de usuarios.

Ayer se publicaban los resultados, tras realizar la encuesta a un total de 1121 usuarios. A continuación muestro un resumen de cada punto que se analizó en la encuesta.

Datos sobre el tipo de usuario

La mayoría de las personas encuestadas eran usuarios habituales de lectores de pantalla (los usan siempre) debido a alguna discapacidad, de entre las que se dan con más frecuencia, están la ceguera o baja visión.

Sólo una pequeña parte de los encuestados, el 8%, se ha declarado usuario principiante, mientras que la mayor parte se considera usuario avanzado.

El programa más usado con clara diferencia es JAWS con un 74%, seguido de Windows Eyes con un 23%. También la mayoría de estos usuarios utilizan la versión más reciente de su programa.

También es muy interesante saber que los usuarios de lectores de pantalla sí personalizan sus programas y cambian las configuraciones por defecto.

Los navegadores más usados son, en primer lugar Internet Explorer 7 con un 68%, seguido de Firefox con un 39% y Explorer 6 con un 33%

Datos sobre el uso de páginas web

¿Qué hacen cuando llegan por primera vez a la home de un sitio desconocido?

La mayoría prefiere leerla entera y otra parte importante prefiere navegar a través de los enlaces de la página.

¿Se usan los links de saltar al contenido y los accesos directos?

En este caso no hay una tendencia que destaque sobre las otras, ya que casi en proporciones iguales se dan los casos en que estos links se usan siempre que existen, se usan a veces, muy raras veces o nunca. Tampoco hay una preferencia clara en cuanto a cuál debería ser el texto del enlace, si bien el 28% prefiere el literal "saltar al contenido principal".

Lo mismo ocurre con las teclas de acceso directo, los accesskeys, aunque en la página nos aclaran que los principiantes en el uso de lectores de pantalla parecen tener más tendencia a usarlas.

Encabezados

En este caso sí que se ve una tendencia clara a navegar por encabezados siempre que están disponibles. Un 52% eligió esta opción y sólo un 7% en total eligieron las opciones de muy raras veces o nunca.

Formularios de búsqueda

La mayoría de los encuestados mostraron tendencia a usarlos o siempre que existen, o con cierta frecuencia, mientras que sólo un 15% dijo usarlos pocas veces o nunca. En WebAIM aprovechan estos resultados para remarcar la importancia, no sólo de proporcionar estos formularios, sino de hacerlo de una forma en la que resulten fáciles de encontrar y usar.

¿Y cómo encuentran el formulario de búsqueda?

La mayoría lo intenta dirigiéndose al primer elemento FORM de la página o al primer cuadro de edición de texto. Una pista clara para saber dónde colocar estos elementos, tan fácil como no intentar reinventar la rueda.

Mapa Web

No parece haber una tendencia clara sobre el uso de los mapas web, si bien se puede extraer la conclusión de que no son muy usados por los usuarios de lectores de pantalla.

¿Se usan las versiones de sólo texto?

En este caso se muestran dos tendencias opuestas: o usarlas siempre que están disponibles o no usarlas casi nunca.

Dificultad de los pop ups

También en este caso los resultados son muy variados. Un 43% en total dice que los pop ups no le resultan muy difíciles, mientras que un 53% parece encontrar dificultades en el uso de pop ups. El análisis detallado de los resultados muestra una relación directa entre la experiencia en el uso de lectores de pantalla y la dificultad que se encuentra en estos elementos, que como es lógico, es mayor en usuarios principiantes de lectores de pantalla.

Accesibilidad de la Web 2.0 y las aplicaciones web dinámicas

Un 54% respondía "no lo sé".

Yo personalmente interpretaría los resultados como "¿Web 2.0? ¿Qué es eso?" y creo sincéramente que la gente de WebAIM le ha echado cierta imaginación al decir que los usuarios de Firefox parecen tener más tendencia a mostrar una respuesta favorable, quizá motivada por el soporte de ARIA en Firefox. Mi opinión es que WAI-ARIA se usa muy minoritariamente y, a pesar de que Firefox tenga soporte, el comportamiento de JAWS ante eventos javascript en este navegador es peor que en Explorer e incluso algo frustrante. Esto es lo yo veo como la triste realidad.

Imágenes decorativas

Aquí aparece un resultado curioso. Las WCAG nos dicen que proporcionemos un alt vacío para las imágenes meramente decorativas, pero los usuarios de lectores de pantalla prefieren mayoritariamente, con un 59%, que sean descritas. Parece que los usuarios más avanzados son los que prefieren encontrar descripciones para estas imágenes, quizá debido a que estos usuarios son más hábiles a la hora de ignorar la información no deseada.

Identificación de fotografías

Para la pregunta "Si la página web contiene una foto de la Casa Blanca, prefiero que la imagen sea identificada como…", un 80% eligió el literal "Foto de la Casa Blanca".

Desde WebAIM nos aclaran que no debemos interpretar este resultado como que todas las imágenes deben ser identificadas como imágenes, es decir, no debemos usar el lireral "Imagen de..", que resulta redundante, ya que el propio lector de pantalla notifica las imágenes como tal.

Identificación de logos

En cuanto al logo con enlace a la home, la mayoría prefiere que sea descrito como "Logo de -nombre del sitio- con enlace a la home".

Parecen ser los usuarios con discapacidades y los más experimentados los que prefieren una descripción más breve.

Múltiples enlaces a distintos sitios con el mismo texto de enlace

Con este tipo de enlaces hacen referencia a los típicos enlaces de "más información" o "ver más" que se repiten a lo largo de una página web.

Casi a partes iguales se dieron las respuestas de encontrar difíciles estos enlaces como encontrarlos fáciles. Nuevamente hay una relación directa entre la experiencia del usuario y la dificultad que encuentra en estos elementos.

Flash

En este caso sí que se ve una tendencia clara a encontrar el contenido Flash difícil o muy difícil. Nada sorprendente.

Marcos

Otra vez nos encontramos a partes iguales con los usuarios que los encuentran fáciles y los que los encuentran difíciles.

En WebAIM nos aclaran que no se hizo distinción entre frames e iframes.

PDF

Se vuelve a repetir una igualdad entre usuarios que lo encuentran fácil y usuarios para los que resulta difícil.

Conclusión

La conclusión que se puede sacar de los resultados de la encuesta es que no existe una formula perfecta que pueda satisfacer por igual a la variedad de usuarios que usan lectores de pantalla y es difícil ofrecer recomendaciones definitivas para muchas cosas, si bien hay puntos que parecen quedar muy claros, como la dificultad del uso de Flash o la importancia de proporcionar encabezados que describan el contenido al que preceden.

Fuente

Encuesta sobre preferencias de usuarios de lectores de pantalla en WebAIM

Sin comentarios

Como ya he comentado más de una vez por aquí, cuando necesitamos ocultar un elemento HTML para mostrarlo u ocultarlo mediante Javascript (un menú desplegable, una capa colapsable, etc), no debemos ocultarlo previamente en el HTML, ya que ese elemento deberá permanecer visible cuando no haya Javascript.

Para ello se pueden utilizar varias técnicas como ocultar estos elementos mediante Javascript añadiendo el estilo display: none, (sí, en la mayoría de casos no será incorrecto que el elemento oculto también lo esté para lectores de pantalla), o bien añadiendo una clase “oculto”, “hidden” o similar definida en la CSS que se encargue de ocultar elementos.

El problema de esta técnica es que cuando no podemos usar alguno de los métodos que nos ofrecen las librerías Javascript para ejecutar funciones cuando el DOM está disponible (ready de jQuery, domready de Mootools o dom:loaded de Prototype), nos encontramos con el feo efecto de que nuestros elementos ocultos aparecen un instante visibles hasta que toda la página está cargada (onload).

Para evitar esto se suelen utilizar otras técnicas no muy limpias de la vieja escuela, como colocar el código Javascript en el HTML, o lo que es peor, usar estilos en línea en la capa o elemento que se ha de ocultar.

Pues bien, gracias a Scriptia, descubro este otro método para ocultar elementos que se basa en añadir una clase al elemento HTML mediante la propiedad documentElement del objeto document. Y cito lo que nos comenta Choan sobre document.documentElement:

  1. Para modificar ‘document.documentElement’ no es necesario esperar a que se complete la carga del documento.
  2. La especificación HTML 4.01 no permite el uso del atributo ‘class’ en el elemento ‘html’. En mi opinión, como la jugada la hacemos por scripting, esto no invalida el documento.

Para utilizarlo nos propone usar una variable en la que detectamos el soporte del DOM por el navegador:


var isSupported = document.getElementById && document.getElementsByTagName;

Y una sencilla instrucción:


if (isSupported) {
    document.documentElement.className = "js";
}

Por último, para evitar tener rondando por ahí una variable global, podemos colocarlo todo dentro de una función anónima autoejecutable, o lo que también se conoce como closure, si no estoy equivocada:


(function(){
    var isSupported = document.getElementById && document.getElementsByTagName;
    if(isSupported){
        document.documentElement.className = "js";
    }
})();

En la CSS aplicaríamos el display none sólo a los elementos hijos de los que tienen la clase “js”:


.js .oculto{ display: none; }

He probado esta técnica en una página en la que he usado 4 imágenes pesadas, para comprobar que la capa que se oculta mediante Javascript, efectivamente lo hace sin necesidad de que la página esté cargada y ¡funciona!

Demo ocultación de elementos mediante javascript.

Por si alguien se pregunta quién va por el mundo con Javascript deshabilitado, no hace falta irse a buscar al usuario de Lynx o a ese otro que por alguna extraña razón decide rebuscar la opción de deshabilitar Javascript en su navegador aunque no sepa lo que es ni le importe. El individuo que va por ahí sin Javascript existe y puede ser perfectamente un usuario avanzado que usa un lector de feeds, un móvil con soporte limitado de Javascript, o ve una web desde su cliente de correo.

Sin comentarios