iPad, recomendaciones de usabilidad para tu web

En este artículo doy 10 recomendaciones extraídas de mi experiencia para que tu web sea más usable cuando es accedida desde un iPad.

Si os interesa el tema os recomiendo: "Usability of iPad Apps and Websitse", de Jakob Nielsen. PDF gratuito de 134 pp. (14.8 MB)

1. Incluye un “favicon” específico para el iPad

Cuando visualizas una página web con el iPad tienes la opción de “Añadir a la página de inicio”.  Esta opción crea un acceso directo en el escritorio cuyo icono es una zona de la web y resulta poco reconocible.

Para personalizar el icono es necesario incluir  la siguiente línea en las páginas:

<link rel="apple-touch-icon" href="/apple-touch-icon.png" />

La imagen debe ser de 72x72 (también coge 57X57, propio del iPhone, pero la resolución evidentemente es menor)

También puedes indicar varios tamaños (el primero es para 57x57):


<link rel="apple-touch-icon" href="touch-icon-iphone.png" />
<link rel="apple-touch-icon" sizes="72x72" href="touch-icon-ipad.png" />
<link rel="apple-touch-icon" sizes="114x114" href="touch-icon-iphone4.png" />

[Ejemplo de Configuring Web Applications de iOS Developer Library]

En el siguiente ejemplo muestro el escritorio con dos enlaces directos a mi blog antes de ponerle una imagen específica y el tercero cuando ya se la he incluido:

2. No utilices Flash

Desde el iPad, de forma estándar, no se puede visualizar Flash ni se puede descargar el plugin para visualizarlo. De hecho, Adobe anunció este mes que abandona Flash para dispositivos móviles.

Es cierto que hay algunas maneras de visualizar Flash, por ejemplo con la aplicación gratuita iSwifter. Pero si quieres que sea accesible para todos debes abandonar el uso de Flash y pasarte a HTML5 (que iPad soporta) o en su defecto ofrecer alternativas.

Recordemos que dar una alternativa a Flash es un requerimiento de las WCAG 1.0, por tanto, si tu web fuera accesible también lo sería en un iPad.

Puede ser tan simple, cuando se trata solo de un banner, como:

<object type="application/x-shockwave-flash" data="flash.swf" width="230" height="100"> <param name="movie" value="flash.swf" /> <param name="quality" value="high" /> <img src="flash.gif" width="230" height="100" alt="Texto aternativo de la imagen" /> </object>

Pongo a continuación algunos ejemplos de cómo se visualizan en el iPad páginas con contenido en Flash:

Web de Disney: no muestra ninguna alternativa al contenido central que es un Flash, solo un texto y un enlace para descargar el plugin (que no podrá descargarse con el iPad)

 

Web de Caprabo: muestra texto alternativo a las animaciones Flash

 

Web Chocapic: es una web en Flash a la que no se podrá acceder. Solo muestra una imagen con un mensaje pero no hay una alternativa en HTML.

 

Web de Vodafone: muestra una imagen alternativa a la animación en Flash y un enlace a la descarga del plugin (que no podrá descargarse en el iPad)

 

El banner superior de elpais.com no muestra ni un mensaje ni una imagen alternativa. Por el contrario, la publicidad interior, que también es en Flash, sí se visualiza como una animación en el iPad:

3. Comprueba que los campos del formulario cogen el foco y lo hacen en un orden lógico

Cuando “tocas” un campo de texto se muestra el teclado de pantalla del iPad. Sobre este teclado aparecen dos enlaces “Anterior” y “Siguiente”

Mediante estos enlaces el usuario se mueve a los campos siguientes y anteriores. Por tanto, asegúrate de que todos los campos cogen el foco y lo hacen en el orden correcto. No hay nada más molesto que tener que volver a la pantalla para seleccionar un campo que no coge el foco.

Este es también un requerimiento de las WCAG, por tanto, volvemos a ver que si tu web es accesible también será más fácil de usar en el iPad.

4. Ayuda al usuario a rellenar los campos del formulario: indica el tipo de campo

Cuando relleno formularios con el iPad me molesta que no reconozca el tipo de dato que se pide y, en función del mismo, me muestre la versión del teclado adecuada.

Y sin embargo hay una manera de hacerlo:

Campo texto: <input type="text" /> 
Campo url: <input type="url" /> 
Campo numérico: <input type="number" /> 
Campo email: <input type="email" />

Los navegadores que no soportan HTML5 lo obviarán y los tratarán como campos de tipo texto (type="text").

Esto lo ví en Tip Precoz 5: teclados de iPhone/iPad. Pongo ejemplos de los diferentes tipos de teclado que se muestran en función del tipo de campo:

Campo type="text"

 

Campo type="url"

 

Campo type="number"

 

Campo type="email"

5. Recuerda que no tienes ratón

Comprueba que tus eventos de ratón funcionan en la pantalla táctil. En el iPad funciona por ejemplo el mouseover, pero te puedes encontrar con problemas asociados al drag&drop, por lo que puede ser necesario traducir los eventos de ratón a eventos táctiles:

Por ejemplo, el siguiente menú no se puede arrastrar con el iPad.

Por ejemplo, el siguiente menú ordenable no se puede ordenar con el iPad.

Por ejemplo, las columnas ordenables de esta tabla no se pueden ordenar con el iPad.

De nuevo nos encontramos con un requerimiento de las WCAG, así que una vez más, una web accesible es una web también accesible para el iPad.

Enlaces interesantes:

• Touch Events version 1 del W3C
• Developing for Multi-Touch Web Browsers de HTML5Rocks.

6. Recuerda que se navega con el dedo

¿Te has medido la yema del dedo? La zona de la yema con la que pulso mide más o menos 1cm x 1cm.

Ten cuidado con el tamaño y la separación entre los enlaces, los botones y los radiobuttons y checkbox para que sea fácil seleccionarlos sin tener que hacer zoom.

Para ello puede ser muy útil cargar una CSS específica para el iPad, donde el tamaño y los márgenes sean mayores.

Un ejemplo rápido (y un poco burdo). Tengo el siguiente formulario (visualizado con Explorer):

Para que sea más fácil de utilizar con el iPad, le he aplicado una CSS específica:

<link rel="stylesheet" media="only screen and (max-device-width:1024px)" href="ipad.css"/>

Efectivamente se aplica solo en iPad y, como se ve, presenta los elementos más grandes y separados:

Solo le falta el toque estético :)

Por ejemplo, en la web de Zara vemos que los iconos son muy pequeños y tanto estos como los menús están muy juntos y resulta muy difícil pulsarlos con el dedo, le vendría bien una CSS específica:

Jakob Nielsen recomienda que los iconos sean al menos de un 1cm x 1cm para que sean fáciles de pulsar con el dedo... supongo que también se ha medido la yema del dedo.

7. Revisa la visualización en vertical y en horizontal

Recuerda que si giras el iPad, tu web también rota y se adapta al ancho vertical u horizontal.

Quizás te puede interesar una CSS diferente para cada caso:

Es interesante el artículo iPad CSS Layout with landscape / portrait orientation modes:

Pero si lo haces, o juegas con el viewport, ten cuidado de que lo estés haciendo bien …

Te explican muy bien el viewport en Configuring the Viewport

Mira este ejemplo de sativapedia.com, en horizontal la web se ve bien, pero en vertical no se adapta y el contenido queda cortado.

Enlaces de interés:

• Configuring the Viewport
• Detect and Set the iPhone & iPad's Viewport Orientation Using JavaScript, CSS and Meta Tags

8. Cuidado con los plugins para escuchar música y ver vídeo

No uses plugins basados en Flash. Por ejemplo en http://www.masvoces.org/ con el iPad no se visualiza el reproductor de audio porque está basado en Flash.

Una buena idea es pasarse a las etiquetas HTML5 <audio> y <video>. Puedes consultar reproductores de video y audio basados en HTML 5 en 10 Beautiful HTML5 Video & Audio Players.

9. Ojo con position:fixed

Cuidado si utilizas en la CSS “position:fixed” porque puede que la capa no aparezca en el iPad donde deseas (cuando defines además un right y bottom para la capa)

La capa que muestro recuadrada en el siguiente pantallazo del iPad, en otros navegadores se ve en la esquina superior izquierda:

Para el uso correcto de “position:fixed” lo mejor es leer el artículo de quiksmode.org The fifth position value

10. ¿Por qué cargar la versión móvil?

En algunos sitios se carga por defecto, cuando navegas con el iPad, la versión para dispositivos móviles, para pantallas pequeñas, muchas veces porque no se está detectando correctamente el User Agent.

Lo he visto en algún blog, pero no digo en cuál para que nadie se dé por aludido. Os recomiendo que lo probéis.

Conclusión

La primera es que soy una pésima fotógrafa.  La segunda que si hacemos web accesibles serán más fáciles de usar en diferentes dispositivos, actuales y venideros.

Pero como conclusión última cito un pasaje de Jakob Nielsen en "Usability of iPad Apps and Websitse", cuando indica que lo más importante es:

First and most importantly, you should test your site. See what the pain points are and then address them. Often fixes will improve the overall usability of your website on the desktop, as well. Some of the more obvious fixes include:

• Getting rid of Flash content
• Creating bigger targets and pad targets so that they tolerate touch better
• Spacing links wherever possible
• Detecting location
• Minimizing the need for typing
• Grouping controls or pieces of information that are related (to avoid having content ignored because it’s below the fold)

Otros enlaces importantes

• Consideraciones específicas que debemos tener en cuenta en páginas web orientadas al navegador Safari en dispositivos iPhone OS e IPAD. de AWS
• ¿Cuán accesible es el iPad a las personas con discapacidades? Fernando A. Cruz

Recursos de interés:

• iPad GUI PSD
• iPhone GUI PSD

Otros artículos de este blog:

• Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.
• Claves para la web móvil
• Formularios usables: 60 directrices de usabilidad
• Aceptar/Cancelar o Cancelar/Aceptar
• Wireframes
• Accesibilidad y usabilidad móvil: web móvil y app nativa

Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página

Nota 2020: consultar tabla resumen en el artículo Ocultar contenido visualmente y/o para el lector de pantalla (tabla resumen).

El objetivo del artículo es explicar cuál es la mejor manera de ocultar visualmente contenido de una página web de tal manera que:

• no comprometa el posicionamiento de la página con prácticas sancionables por Google
• asegure la accesibilidad de las páginas para aquellas personas que utilicen lectores de pantalla

¿Qué texto podemos desear ocultar? ¿deberíamos ocultarlo?

En un desarrollo accesible hay dos ejemplos típicos y habituales en los que se plantea ocultar texto:

• el enlace “Saltar al contenido” que suele incluirse al comienzo de las páginas. Según la encuesta “Survey of Preferences of Screen Readers Users” de WebAim de 2009, el 38% de los usuarios de lectores de pantalla lo utiliza siempre que puede o a menudo y el 24% algunas veces (otros prefieren saltar de encabezado en encabezado). Recordemos que incluir este tipo de enlace es de prioridad AAA en las WCAG 1.0 (punto de verificación 13.6) y de prioridad A en las WCAG 2.0 (criterio de verificación 2.4.1)
• el texto complementario a los enlaces del tipo “Leer más”, puesto que deben evitarse enlaces con el mismo texto pero con vínculos a páginas diferentes. Por tanto, cada uno de los enlaces “Leer más” (por ejemplo asociados a los titulares de varias noticias) es en realidad “Leer más sobre la Noticias 1”, “Leer más sobre la Noticia 2”, pero el texto que sigue a “Leer más” se oculta a la vista. Recordemos que evitar este tipo de enlaces con texto igual pero vínculo diferente es un requisito AA en las WCAG 1.0 (punto de verificación 13.1) y A o AAA en las WCAG 2.0 en función de si es comprensible el enlace en el contexto (criterio de verificación 2.4.4 y 2.4.9)

Por tanto se dan casos en los que para cumplir con las pautas de accesibilidad puede que pensemos que hay que ocultar algún texto. Digo que “puede que pensemos” puesto que antes de tomar esta decisión habría que meditar si es realmente necesario o conveniente ocultarlo.

Por ejemplo, en el primer caso, si bien es cierto que el enlace “Saltar al contenido” beneficia a los usuarios que utilizan lectores de pantalla porque les permite alcanzar el contenido principal de una forma sencilla y rápida (evitándoles escuchar la cabecera y el sistema de navegación en todas las páginas antes de llegar al contenido) también beneficia a las personas que acceden con el teclado, a aquellos que utilizan magnificadores de pantalla o a los que acceden desde un dispositivo móvil.

Sería por tanto recomendable incluirlo siempre visible, pero a veces se imponen otros criterios estéticos. Solo quería dejar ahí la reflexión. Pasemos ahora a ver, si los ocultamos, cómo deberíamos hacerlo.

Display:none

Aplicar el estilo display:none a un elemento de una página lo hace totalmente invisible: no genera una caja, no ocupa lugar, no afecta a la disposición. Oculta el elemento y sus descendientes no sólo visualmente sino también a los lectores de pantalla.

Para saber exactamente cómo interpretan diferentes lectores de pantalla display:none (pues no es cierto que todos los lectores de pantalla en todos los casos y con todos los navegadores no lean un elemento oculto con display:none) recomiendo el artículo de agosto de 2011 “JAWS, Window-Eyes and display:none: Return to 2007” de Jason Kiss.

Sobre el uso de display:none recomiendo el artículo “Do not use display:none to visually hide content intended for screen readers” de Roger Johansson.

Visibility:hidden

Con visibility:hidden ocurre algo similar, el contenido así oculto no siempre será leído por los lectores de pantalla, pero estos tampoco lo interpretan como un display:none. Por eso, cuando lo que se quiere es que algo esté oculto visualmente y oculto para todos los lectores de pantalla (lo contrario que estamos tratando aquí, que queremos ocultarlo visualmente pero que sea leído por los lectores de pantalla) lo que se recomienda es que se oculte con ambos:

.hide { display: none; visibility: hidden; }

Recomiendo leer el artículo “Screen readers sometimes ignore display:none” de Roger Johansson y el estudio “Empty Links and Screen Readers” de yuiblog.com donde se muestran esquemáticamente los resultados de utilizar display:none y visibility:hidden con diferentes navegadores y lectores de pantalla.

En cualquier caso, ni display:none ni visibility:hidden cumplirían el requisito que necesitamos de que el texto oculto sea leído por todos los lectores de pantalla.

Height:0

.element-invisible { height: 0; overflow: hidden; position: absolute;}

Hubiera estado bien, pero Jeff Burnz indica en “Using CSS clip as an Accessible Method of Hiding Content”, que desgraciadamente, aunque NVDA y Jaws leían el contenido, Voice Over (en dispositivos Apple) no lo lee.

Posicionar el texto fuera de pantalla

Por ejemplo con text-indent:-999em (no aplicable a los lenguajes que se leen de derecha a izquierda) o top: -999em;

Esta técnica es accesible para los lectores de pantalla. Pero debe tenerse en cuenta también a los usuarios que no usan un lector de pantalla y asegurarse de que el foco se haga visible. No puede ser que una persona que accede con el tabulador pierda el foco porque este se ha ido a una serie de elementos ocultos situados fuera de pantalla, de tal manera que debe tabular varias veces, sin saber dónde está el foco, hasta que este vuelve a ser visible.

Fijaros cómo lo resuelve la página Department of Homeland Security


a#skip, a#skip:hover, a#skip:visited {position:absolute; top:-100px; width:1px; height:1px; overflow:hidden; font-size:x-small;}

a#skip:active, a#skip:focus {position:static;width:auto;height:auto;text-align:center;margin:0 auto}

<a href="#content" id="skip" accesskey="2">Skip Navigation</a>


El enlace está fuera de pantalla, pero cuando el enlace coge el foco este se hace visible.

Os recomiendo también el artículo “Skip Navigation Links” de James W. Thatcher, donde recuerda también el tema del tabindex=”-1” y las anclas en Explorer.

Puede parecer entonces que esta opción, bien implementada, sería la solución ideal. Sin embargo surge la duda de si podemos tener un problema con el posicionamiento de la página.

Google dice que penaliza el contenido que se oculta, y contenido con text-indent negativo parece fácil de rastrear. Da igual que lo incluyas en la CSS porque también analiza las CSS. Si las restringimos en el fichero “robots.txt” no quiere decir que Google no pueda acceder a ellas y entonces puede que sí seamos realmente sospechosos.

¿Se debe por tanto dejar de utilizar text-indent negativo por miedo a ser penalizado? He estado leyendo experiencias de mucha gente y todos parecen coincidir al final en lo mismo: lo utilizan sin sufrir penalización cuando se hace sin intención maliciosa, es decir, cuando el texto oculto no incluye un relleno de palabras clave, así lo dicen incluso desde Google, cuya página, al fin y al cabo también utiliza el posicionamiento fuera de pantalla.

Resultan muy ilustrativos los comentarios del artículo ”Google, SEO and using CSS to hide text” o el artículo “Demystifying Google's text-indent mystery”

En fin, que después de horas leyendo no he encontrado a nadie que diga que utilizando text-indent de forma legítima, como los ejemplos que he expuesto, le hayan penalizado.

Aun así nos queda una última técnica.

Clip

.element-invisible {
position: absolute !important;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

Está técnica es explicada en “Using CSS clip as an Accessible Method of Hiding Content”. Según se indica, el texto así oculto trabaja en todos los navegadores y es leído por Jaws, NVDA y Apple Voice Over. En realidad hay que retocarlo para que esto sea realmente así según se explica en “Clip your hidden content for better accessibility”, de Thierry Koblentz.

Esta técnica la podemos mejorar para el tema del foco (cuando lo que ocultamos son elementos que cogen el foco, por ejemplo un enlace), tal y como veíamos en el ejemplo anterior, de tal manera que cuando coja el foco ponemos "clip" a "auto" y "position" a "static"

Por otra parte, Google no penaliza esta práctica. Así que parece la solución ideal: accesible y no compromete el posicionamiento. Pero siempre hay una pega, en este caso que clip: rect(1px 1px 1px 1px); no pasa el validador de sintaxis CSS. Resulta que IE6 y IE7 no siguen la especificación y para que funcione en estos navegadores los parámetros deben separarse sin comas.

Mi opinión es que, si las definiciones específicas para determinados navegadores:

• no provocan conflictos con otros navegadores
• no suponen un problema de accesibilidad
• se agrupan en una CSS independiente

no deben coartar que se utilicen en aras precisamente de mejorar la accesibilidad de las páginas.

Conclusión

• No usar display:none, visibility:hidden, ni height:0, puesto que no aseguran la accesibilidad de los textos ocultos en todos lectores de pantalla.
• Se puede usar el posicionamiento fuera de pantalla porque es accesible, siempre y cuando lo utilices de forma lícita y no para incluir palabras clave, de lo contrario puedes ser penalizado.
• Se puede usar la técnica del clip porque es accesible y no provoca problemas con el posicionamiento de la página, pero tienes que ser consciente de que la CSS no pasará el validador de sintaxis del W3C.

Descarga mi capítulo ampliado "Accesibilidad y SEO" (PDF, 248) del libro "Pioneros y Hacedores. Fundamentos y Casos de Diseño de Interacción con estándares de Accesibilidad y Usabilidad" , 2013, Lorena Paz (comp.)

Artículos relacionados:

• SEO y Accesibilidad. Accesible también para buscadores
• Sobre el uso de lectores de pantalla