jueves, 23 de enero de 2014

Responsive Design y accesibilidad. Buenas y malas prácticas. Errores comunes.

Índice

Responsive Design. ¿Qué es?

Responsive Web Design (RWD) es una técnica de diseño y desarrollo de sitios y aplicaciones web que permite que las páginas se adapten al tamaño, la resolución y orientación de la pantalla, y por tanto al dispositivo del usuario. Y todo ello con un código único, una única página, una única URL.

Tenéis 50 ejemplos de Responsive Web Design en el artículo “Responsive Web Design: 50 Examples and Best Practices”, designmodo.com, octubre 2011

No necesitas realmente visualizar estas páginas en diferentes dispositivos para comprobar que son Responsive Web Design, basta con que las visualices desde tu escritorio y redimensiones la pantalla del navegador. Según el tamaño de la pantalla verás que el diseño, la navegación, el contenido y las imágenes se reconfiguran automáticamente.

También puedes cambiar la resolución de pantalla, selecciona una resolución baja y podrás ver la visualización de la web para esa resolución.

A medida que hacemos la pantalla más pequeña o bajamos la resolución, pasamos por ejemplo de un layout de 3 columnas a uno de 2 y finalmente a un layout de una columna. Las imágenes se hacen más pequeñas para adaptarse al espacio disponible o el sistema de navegación se modifica.

Podéis consultar el artículo de Juan Carlos Mejía [MEJIA, 2012] donde incluye varios vídeos que ilustran todo ello con claridad.

Responsive Design. ¿Cómo se hace?

Esta flexibilidad se consigue mediante el uso de un código HTML único pero que se presenta de manera diferente gracias a:

  • La separación entre el contenido y la presentación: todos los estilos están definidos en las CSS.
  • Layouts basados en grids: la información se organiza en ejes verticales y horizontales. Tendremos definidos diferentes layouts en diferentes CSS, por ejemplo uno de 3 columnas, uno de 2 columnas y uno de 1 columna.

    Tres esquemas de una web. El esquema a tres columnas se verá en resoluciones de escritorio. La versión a dos columnas en tablets, y la versión a una columna en móviles.

    Imagen de boatboatool.com

  • Fluids Grids, es decir, el uso de medidas relativas que permitan que el contenido se pueda adaptar realmente como se ve en la imagen anterior. Permite utilizar todo el espacio disponible y evitar el desplazamiento horizontal.
  • Media Queries, permite cargar dinámicamente las diferentes CSS que hemos definido en función del tamaño de pantalla, su resolución o su orientación.

    <link rel="stylesheet" type="text/css" href="style2col.css" media="all and (min-width: 400px) and (max-width: 800px)" />

    En este ejemplo se especifica la CSS a utilizar (layout de 2 columnas) con un viewport (la parte de pantalla donde se representa el documento) de una anchura entre 400px y 800px.

    Media Queries son recomendación del W3C desde junio de 2012.

    En la bibliografía, al final del post, tienes algunos artículos relacionados con la resolución y tamaño de los diferentes dispositivos y cómo aplicar Media Queries: [CHELARIU, 2013], [CARRERAS, 2014], [ANDROID], [PRIETO, 2014]

  • Configuración del meta viewport: mediante este meta indicamos que nuestra web es flexible para adaptarse a los diferentes anchos y resoluciones de pantalla, le indicamos al navegador que no aumente o reduzca la página, que use el zoom por defecto.

    <meta name="viewport" content="width=device-width,initial-scale=1.0" />

    Con el uso combinado de Media Queries y la definición del viewport evitamos que nuestra web se vea en miniatura en un dispositivo móvil, que tengamos que hacer zoom y después tener que desplazarnos porque el contenido ocupa más que el ancho de pantalla. Por el contrario, ahora se verá a tamaño real y ajustado a todo el ancho.

    Más adelante veremos cómo, sin embargo, es importante desde un punto de vista de accesibilidad no impedir que el usuario pueda hacer zoom si lo desea. Indicaré cómo evitar una incorrecta configuración del viewport.

  • Imágenes y vídeos de tamaño flexible, que también se adapten al espacio disponible. Se puede conseguir de diferentes maneras, cada una con sus ventajas e inconvenientes. Más adelante hablaré de cómo algunas de ellas tienen implicaciones en la accesibilidad de la página.

    En el caso de los vídeos podemos usar HTML5 y el elemento <video> con diferentes sources según la resolución. Tenéis un ejemplo en el artículo de Ian Devlin [DEVLIN, 2012]

    En el caso de las imágenes, Chrome 38 y Opera 25 ya soportan el futuro elemento de HTML5 <picture>, que al igual que <video>, permite definir varios recursos (imágenes en este caso), una para cada resolución. Os hablo de este elemento y su soporte actual por los navegadores y productos de apoyo en el artículo LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5) .

    Otros técnicas que se suelen utilizar son:

    • La imagen se define como fondo de un elemento en las CSS (background-image) Se tienen diferentes versiones de la imagen a diferentes tamaños, en cada CSS se carga una de ellas. Veremos que aunque es más óptimo para aligerar el peso de las páginas, puede suponer un problema grave de accesibilidad si las imágenes así definidas no son decorativas sino informativas.
    • La imagen se incluye en el código HTML con el elemento IMG pero se define su anchura y altura en las diferentes CSS. El gran inconveniente es que aunque muestras la imagen a diferente tamaño en realidad se carga siempre la de mayor peso.
    • Los logotipos e iconos se incluyen con SVG adaptándolos mediante media queries. Podéis consultar varios ejemplos en [PUKHALSKI, 2014] [SOUEIDAN, 2014] En estos casos debemos tener en cuenta que en SVG también podemos incluir títulos y descripciones como comenté en LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5) .
    • Los logotipos e iconos se incluyen como fuentes personalizadas que añades con @font-face. Esta técnica provoca serios problemas de accesibilidad si no se incluyen con su correspondiente alternativa textual. Si la letra "a" de la fuente personalizada es el icono de "home", el lector de pantalla leerá "a" en vez de "página principal" a menos que pongamos la correspondiente alternativa textual.
    • Otras opciones que ya no son propiamente Responsive Design son detectar el dispositivo en el servidor para servir las diferentes versiones de la imagen según el dispositivo, o usar javascript, cookies [W3C_GROUP, 2012].

En cuanto a la metodología de trabajo es muy importante tener ya presente, no solo en la etapa de diseño, sino también en la de conceptualización y prototipado, cómo será el sitio en función del tamaño de pantalla.

Desde 2009 Luke Wroblewski viene defendiendo un enfoque Mobile First, basado en el principio de Mejora Progresiva. Pensar primero en la versión móvil y después ir añadiendo complejidad mediante Media Queries, que serán ignoradas por los navegadores que no las soporten. Este enfoque, dada las limitaciones de las pantallas pequeñas, te permite centrarte en las necesidades reales de los usuarios, priorizar las tareas claves:

LONGDESC. Soporte y alternativas (WCAG 2.0, ARIA, HTML5)

Los dispositivos móviles requieren que los equipos de desarrollo de software se centren únicamente en los contenidos y en las acciones más importantes de la aplicación. Simplemente no hay espacio en una pantalla de 320x480px para los elementos innecesarios. Hay que priorizar.

Así que, cuando un equipo diseña primero para el móvil, el resultado final es una experiencia centrada en las tareas clave que los usuarios quieren lograr, sin distracciones […] Eso es bueno para la experiencia de usuario y bueno para los negocios.

[WROBLEWSKI, 2009]

Para ampliar cómo se aplica técnicamente Mobile First, cómo se define primero la CSS para los tamaños de pantalla más pequeños impidiendo que esta sea la que se cargue en versiones anteriores a IE9, se puede leer el artículo de Ricardo Prieto [PRIETO, 2014].

Relación entre Responsive Design y accesibilidad

Un sitio desarrollado con la técnica Responsive Design no implica que dicho sitio vaya a ser accesible y a cumplir con las pautas de accesibilidad [WCAG2, 2008], sin embargo es un gran punto de partida.

Parten de un enfoque o filosofía similar: defienden una web única, que los sitios sean flexibles, independientes del dispositivo y a disposición de todos los usuarios.

Hay ciertos requisitos de accesibilidad, a nivel de código, que tienen gran impacto en la accesibilidad de las páginas y que deben tenerse en cuenta desde el comienzo del desarrollo, pues son muy costosos de corregir a posteriori: el uso de estándares, la separación entre el contenido y la presentación, el uso de medidas relativas, evitar las tablas para maquetar o la definición de jerarquías de información estructuradas correctamente.

Como hemos visto, un sitio Responsive Design cumple per se con muchos de estos requisitos.

Por otra parte, también hemos comentado que la metodología Mobile First va más allá de la mera adaptación del sitio al tamaño de pantalla. Ahora, cada pieza de información, cada enlace, debe ganarse su lugar. Esto ayuda a priorizar contenidos y funcionalidades eliminado lo innecesario: las páginas son más cortas y sencillas y la navegación más racional.

Como resultado tendremos sitios más fáciles de navegar y entender, con menor carga cognitiva y visual.

Como defiende Luke Wroblewski [WROBLEWSKI, 2010] la metodología Mobile First para Responsive Design ayuda a que las páginas sean más accesibles Favorece a todos los usuarios, pero sin duda especialmente a los usuarios con discapacidad cognitiva, a los usuarios que utilizan lectores de pantalla o a los usuarios que tienen una discapacidad motora y utilizan dispositivos de entrada alternativos.

Concretando, ¿cómo puede favorecer a la accesibilidad de un sitio que este sea Responsive Design?

  • El contenido y la presentación están separados, los estilos están definidos en las CSS y no se usan tablas para maquetar. Todo ello beneficia a las personas con diferentes discapacidades al permitir a los agentes de usuario adaptar el contenido de acuerdo a sus necesidades (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • Tendencia a un mayor respeto por los estándares web, lo cual maximizará la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas (pauta 4.1, [WCAG2, 2008])
  • Tendencia a tener la información estructurada y jerarquizada más correctamente (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • Tendencia al uso de elementos semánticos para poder definir sus estilos en las CSS. Indicar explícitamente la función estructural o valor semántico del contenido permitirá que esta información se pueda determinar mediante software favoreciendo la accesibilidad (criterio de conformidad 1.3.1, [WCAG2, 2008])
  • El diseño flexible y la definición de tamaños relativos permiten que el texto se pueda ampliar sin desbordamientos y hacer zoom con garantías (criterio de conformidad 1.4.4, [WCAG2, 2008])
    • El tamaño flexible de las imágenes y vídeos permitirá que se adapten mejor al espacio disponible sin que se superpongan con otros contenidos.
    • Mejor experiencia para los usuarios con baja visión que suelen tener resoluciones de pantalla más bajas y suelen ampliar la pantalla.
  • Además, el diseño flexible y que no se usen tablas para maquetar ayuda a garantizar un orden de lectura correcto. Los diseños fluidos tienden a presentar el contenido en el mismo orden que el DOM y este es el mismo orden en que, por ejemplo, los lectores de pantalla leerán el contenido (criterio de conformidad 1.3.2, [WCAG2, 2008])
  • Se tiene muy presente que el sitio se visualizará en distintos dispositivos y por tanto:
    • Es más probable que tu sitio no sea operable solo con el ratón, la forma de interactuar ahora es muy variable y esto ayuda al diseño inclusivo (principio Operable, [WCAG2, 2008])
    • Es más probable que mejores el contraste de color, que suele ser más pobre en los dispositivos móviles ya que bajamos el brillo para ahorrar batería, además de que son habituales los reflejos en la pantalla (criterios de conformidad 1.4.3 y 1.4.6, [WCAG2, 2008])
    • Mayor uso de la técnica Progressive Enhancement (Mejora Progresiva) que consiste en una implementación básica, que funciona a través de múltiples dispositivos y con una amplia gama de tecnologías de asistencia, añadiendo después más funcionalidades para los dispositivos que las soportan.
  • Focalizarse solo en lo necesario, priorizar y simplificar, dará como resultado sitios más fáciles de navegar y entender, con menor carga cognitiva y visual, mejorando la legibilidad y la accesibilidad.
    • Mayor uso de la técnica Progressive Disclosure (Revelación Progresiva), que se basa en diferenciar el contenido primario del secundario. El contenido primario aparece inmediatamente en el flujo normal de la página y es muy visible. El objetivo es mostrar solo lo relevante para el usuario en este momento. Nos beneficia a todos, pero especialmente a los usuarios con discapacidad cognitiva o con déficit de atención, y bien hecho facilita la navegación a los usuarios de lectores de pantalla o a las personas con discapacidad motora.

No es oro todo lo que reluce

Si terminara el artículo aquí podría parecer que Responsive Design es la panacea para la accesibilidad, pero no es así. La mayoría de las veces los desarrollos no cumplen con todos los puntos enumerados anteriormente. También nos encontramos con problemas recurrentes y malas prácticas que suponen barreras de accesibilidad en los desarrollos Responsive Design.

A continuación el artículo se centra en dichos problemas.

Primera norma de accesibilidad para Responsive Design

Como hemos visto, la accesibilidad no tiene por qué verse comprometida en los sitios Responsive Design, sino que por lo general suelen cumplir con ciertos requisitos de accesibilidad y es una buena base para comenzar a trabajarla.

Sin embargo no siempre es así, habrá ciertos aspectos a los que prestar especial atención porque nos encontramos con problemas recurrentes y extendidas malas prácticas.

La primera norma, y más importante, es que habrá que comprobar la accesibilidad en las diferentes resoluciones establecidas mediante Media Query.

Puede parecer una tontería, puesto que hemos dicho que la página es la misma y que simplemente se cargan distintas CSS, pero no lo es.

Muchas veces se ocultan contenidos en las versiones para tamaños de pantalla más pequeños. Para que determinado contenido no se muestre, a veces lo ocultan con estilos definidos en la CSS para las resoluciones más bajas. Otras veces se hace detectando el dispositivo desde el servidor o por javascript. Todo eso no es Responsive Design, pero son prácticas habituales que, mal hechas, suelen generar problemas de accesibilidad.

A continuación voy a poner 5 típicos ejemplos de errores de accesibilidad que:

  • NO encontramos cuando accedemos a la página con el mayor tamaño o resolución definido
  • pero encontramos cuando reducimos la resolución o el tamaño de pantalla, y que son consecuencia de la ocultación de contenido mal implementado o sin medir sus consecuencias.

1. Los encabezados ya no tienen una jerarquía correcta

Hemos dicho que no solo se adapta la visualización sino también a menudo el contenido, eliminando zonas de información en las versiones con resoluciones menores. Cuando cierto contenido desaparece la jerarquía de encabezados puede verse comprometida.

Veamos la página Mashable.

Tenemos un encabezado H1 con el logo, un H2 con la categoría “Tech” y un H3 “Media Trends 2013” (en realidad en la página se saltan un nivel y “Media Trends 2013” es H4, pero vamos a imaginarnos que lo hubieran hecho bien porque para el ejemplo es indiferente)

Parte superior de la página Mashable. El logo es H1, la categoría en H2, el título de la primera zona de contenido es H3

Encabezados de Mashable a una resolución alta

En la imagen que sigue, vemos la misma página al tamaño más reducido de pantalla. El contenido se ha simplificado. Se ha eliminado el H2 “Tech” (tanto visualmente como para los usuarios de lectores de pantalla) junto con la barra de redes sociales. Como consecuencia, tras el H1, nos encontramos con un H3. La jerarquía de encabezados ya no es consistente y esto dificulta ojear el documento cuando accedes con el lector de pantalla.

Parte superior de la página Mashable en resoluciones bajas. El logo es H1, el título de la primera zona de contenido es H3

Encabezados de Mashable a una resolución baja

2. Enlaces para saltar el contenido que ahora solo crean ruido

Estamos en un caso similar al anterior. Si has eliminado o simplificado contenido debes comprobar que los enlaces para saltar contenido ahora siguen teniendo sentido, o si simplificada la página, estos solo crean ruido. Lo mismo puede ocurrir con otros elementos, como los WAI ARIA landmarks (ver artículo Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA) ).

Hay un artículo de Henney Swan [SWAN (b), 2012] que habla sobre los enlaces de saltar contenido en Responsive Design.

3. El contenido se oculta de forma inadecuada

En el caso de que estemos ocultando contenido en las CSS es importante comprobar cómo se está ocultando.

En el artículo "Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página" explicaba las diferentes técnicas para ocultar contenido. En función de cómo lo ocultes, el contenido estará también oculto o no para los lectores de pantalla:

  • Display:none o visibility:hidden, el contenido tampoco estará disponible para los lectores de pantalla.
  • Text-indent:-9999 o la ocultación mediante clip, el contenido sí estará disponible para los lectores de pantalla.

Si en la versión para tamaños de pantalla pequeños has ocultado contenido al usuario para simplificar la página, asegúrate de que también esté oculto para los lectores de pantalla, de esta manera estarán en igualdad de condiciones.

Si ocultas unos contenidos con una técnica y otros con otra, sin ningún criterio, la página puede llegar a ser incomprensible para ellos.

En el apartado 4, sobre problemas en la navegación, veremos también un ejemplo de contenido oculto de forma incorrecta.

4. El menú de navegación ahora es diferente, ¿es accesible?

En las versiones para las menores resoluciones o tamaños de pantalla el menú suele convertirse hoy en día, casi un estándar de facto, en un icono con tres rayitas que se despliega.

Pasamos de tener un menú lineal y visible a un menú desplegable, y es por tanto importante asegurarse de que la navegación sigue siendo accesible para todos los usuarios.

Los tres ejemplos que pongo a continuación están basados en la modificación de las CSS, el código HTML es el mismo para las dos visualizaciones.

Ejemplo 1: http://www.starbucks.com/

Sistema de navegación lineal: menú con 6 opciones visibles

Menú de navegación con resoluciones de pantallas mayores

Sistema de navegación colapsado bajo un icono. El menú se despliega al pulsar el icono mostrándose bajo el mismo.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla nos anuncia el icono “Enlace Navigation” (Icono para desplegar el menú), si lo seleccionamos nos lee “Lista con seis elementos” y podemos acceder a sus enlaces. Sin problemas.

Pero si después de que me anuncie “Enlace ‘Navigation’” yo decido seguir adelante sin pulsarlo… vaya, también me anuncia “Lista con seis elementos” y tengo la navegación aunque no la he solicitado. Resulta un tanto confuso. No la has ocultado correctamente.

Ejemplo 2: http://antocas.com/demos/menu-responsive-design/

Menú de navegación lineal con cuatro opciones de menú visibles

Menú de navegación con resoluciones de pantallas mayores

Menú de navegación colapsado bajo un icono. Cuando se pulsa el icono el menú se muestra encima del icono.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla me anuncia el icono “Enlace ‘Nav Menu’” (Icono para abrir el menú ) Si no lo pulso accedo al resto del contenido de la página correctamente, al contrario que en el ejemplo anterior. Sin embargo, cuando lo pulso… no consigo encontrar el supuesto menú desplegado. ¿Por qué? Porque el orden de lectura no es correcto. El código del menú está encima del código del icono. Tengo que adivinar que solo pulsando por ejemplo la flecha arriba conseguiré llegar a él.

Ejemplo 3: http://bradfrostweb.com/blog/web/complex-navigation-patterns-for-responsive-design/

Menú lineal con cinco opciones visibles

Menú de navegación con resoluciones de pantallas mayores

Menú colapsado bajo un enlace 'Menú' acompañado de una flecha. Cuando pulso el enlace el menú se despliega encima del enlace.

Menú de navegación con resoluciones de pantallas menores

En la segunda versión, la versión para resoluciones de pantalla más pequeñas, el lector de pantalla nunca puede acceder al enlace “Menú”. Lee siempre las opciones de menú al comienzo de la página como si estuviera en la navegación para escritorio, como si siempre estuvieran visibles, esté o no el menú desplegado. No se ha manejado correctamente la ocultación de los elementos.

5. Asegúrate de que el orden de lectura ahora también es correcto.

Un desarrollo responsive suele favorecer que el orden de lectura sea adecuado, pero cuando se empieza a ocultar contenido es importante asegurarse de que el orden de lectura sigue siendo correcto.

En el punto anterior ponía un ejemplo (ejemplo 2) de un orden de lectura incorrecto en un menú de navegación desplegable.

Otras consideraciones de accesibilidad a tener en cuenta

Hemos visto en el apartado anterior errores comunes relacionados con ocultar contenido en las versiones móviles de manera inadecuada o sin tener en cuenta las consecuencias para la accesibilidad de la página.

Ahora vamos a ver otras malas y buenas prácticas que hay que tener en cuenta.

Malas prácticas

Explico a continuación tres malas prácticas que hay que evitar.

Mala práctica 1: Tratar imágenes informativas como imágenes decorativas para cargar diferentes tamaños de imagen

Si incluyes las imágenes en el código y quieres mediante las CSS que se muestren a diferente tamaño, puedes definir su ancho y su alto en las diferentes CSS. El problema es que la imagen que descargas es siempre la misma, la más grande, y solo estas cambiando su tamaño de visualización.

Para intentar evitarlo, un error común es tratarlas como imágenes decorativas, de fondo (definidas en el background-image de un elemento) de esta manera puedes tener diferentes tamaños de la imagen y en cada CSS cargar una.

Utiliza cualquier otra técnica menos esta: tratar imágenes informativas como imágenes decorativas supone un grave problema de accesibilidad, pues las imágenes decorativas no tienen una alternativa textual y si, por diferentes motivos, no se cargan o el usuario no puede verlas (por ejemplo accede con un lector de pantalla), se perderá la información que transmiten.

Mala práctica 2: Definir el viewport con restricción para el zoom

Si el usuario lo desea debe poder hacer zoom con el gesto “pinch” (Gesto con el dedo pulgar e índice, se abren o cierran como una pinza) al menos un 200% (criterio de conformidad 1.4.4, [WCAG2, 2008]). Para ello es importante definir correctamente el viewport:

Mala práctica:

<meta name="viewport" content="width=device-width;initial-scale=1.0; maximum-scale:1.0; user-scalable=1" />

Defiendo así el viewport estamos impidiendo el zoom. Podemos ver un ejemplo en la web http://www.anderssonwise.com/

Buena práctica

<meta name="viewport" content="width=device-width;initial-scale=1.0; maximum-scale:2.0; user-scalable=1" /<

Definiendo así el viewport estamos permitiendo que los usuarios que lo deseen puedan hacer un zoom de hasta 200%.

Mala práctica 3: Ocultar la barra de scroll horizontal

No debes ocultar la barra de scroll horizontal con overflow-x: hidden;

Tu sitio ya se adapta al dispositivo sin barras de scroll, ¿para que la ocultas además si no es necesario? Puede haber circunstancias en las que los usuarios la necesiten, por ejemplo si hacen zoom.

Buenas prácticas

A continuación indico cuatro buenas prácticas que deberías llevar a cabo en tu desarrollo Resposive Design. Y por supuesto la mejor recomendación es que las páginas cumplan con las pautas de accesibilidad WCAG 2.0

Buena práctica 1: Contraste de color mejorado en la versión para las resoluciones o tamaños de pantalla más pequeños.

Para alcanzar el nivel de adecuación AA respecto a las WCAG 2.0, el color de los textos debe tener al menos un ratio de contraste de 4.5:1 (3:1 en texto grandes) Para alcanzar el nivel AAA el contraste debe ser de 7:1 (4.5:1 en textos grandes)

Puesto que tenemos una CSS para dispositivos móviles os animo a que en ella alcancéis un nivel de contraste de color mayor, llegando al nivel AAA. En los dispositivos móviles el contraste suele ser menor, para ahorrar batería, y solemos tener muchos reflejos. También es importante que subrayéis los enlaces para reconocerlos mejor.

Se puede comprobar el contrate de color con la herramienta gratuita Colour Contrast Analyser.

Buena práctica 2: Diseña el tamaño de los elementos y la separación entre los mismos pensando también en los dispositivos móviles

En la web para desarrolladores de Android [ANDORID] tenéis resumida de forma gráfica cuáles deberían ser los tamaños y espacios mínimos para que tus elementos sean fáciles de pulsar desde dispositivos táctiles. Nos ayuda a todos y especialmente a las personas con discapacidad motora:

Ten además en cuenta que hay zonas de pantalla más fáciles de pulsar.

Buena práctica 3: El foco sigue siendo importante en los dispositivos móviles

Sigue siendo importante, tanto que el foco sea visible (no debes ocultarlo en la CSS) como que el orden del foco sea correcto. Muchos usuarios utilizan teclados externos o los usuarios de lector de pantalla deslizan el dedo por la pantalla tabulando de un elemento a otro.

Buena práctica 4: Prueba

Testea tu página, pruébala sin CSS o sin imágenes cargadas, pruébala con un lector de pantalla, prueba con usuarios y si tienes la oportunidad con usuarios con discapacidad. Henny Swan tiene un artículo muy interesante con una lista concreta de comprobaciones recomendadas [SWAN, 2012].

También deberías conocer las Mobile Web Best Practices del W3C, recomendación desde 2008. Hablé de estas y su relación con las WCAG en el artículo "Accesibilidad y usabilidad móvil: web móvil y app nativa", blog Olga Carreras, mayo 2012.

Bibliografía

Artículos relacionados

Servicios de accesibilidad web que ofrezco como consultora freelance

14 comentarios :
Ricardo Prieto dijo...

Enhorabuena por el artículo Olga, muy completo.

Es muy importante como bien comentas, siempre que las condiciones y tendencias cambian en temas tan volátiles como el diseñó, tener muy presente la experiencia de usuario. Creo que con el Responsive Design si se está haciendo bien, el usuario forma parte de los condicionantes y el proceso de trabajo y eso es importante (no como ocurrió con Flash, por ejemplo)

En cuanto a la tipografía, como bien indicas, la tendencia es cambiar los pixeles por unidades relativas, para que sea el usuario el que pueda decidir el tamaño de letra según sus condiciones de accesibilidad (según dispositivo). Vamos de px a em o rem, aunque personalmente creo que esta última (unidades relativas con respecto a la raiz, que deberá ser font-size: 100%, es decir la que haya decidido el usuario en la configuración de su navegador) es la que se terminará imponiendo.

lo dicho, gracias por el artículo y la mención ;)
Un saludo

Surien dijo...

Siento no tener nada mejor que decir, pero vaya PASADA de artículo. Ayuda mucho para los que estamos empezando ;).

Ferdi dijo...

Gran artículo... probablemente el más completo de los que he leido

AJ dijo...

Muy buen artículo, y excelente la bibliografía incluida.
Sólo quería indicar que para comprobar los niveles de contraste en cualquier pagina web, existen add-ons específicos.
Por ejemplo para Chrome: https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll
Y para Firefox: https://addons.mozilla.org/es/firefox/addon/wcag-contrast-checker/

Olga Carreras dijo...

Recurso interesante:
http://viewportsizes.com/

Anónimo dijo...

Si la información de la red fuera tan clara como la de este artículo, todos tendríamos las cosas mucho más claras a la hora de desarrollar.
Felicidades y, por favor, no pares.

Diseñando y maquetando desde el 2000,

interas dijo...

Un artículo excepcional como siempre. Solo tengo una duda, pensaba que en las WCAG2.0 no importaba el orden de aparición de los encabezados, de tal manera que entiendo que el ejemplo es correctamente erróneo pero si los encabezados fueran H1 H3 H2, esto sería correcto???

Olga Carreras dijo...

Hola, el tema del orden de los encabezados lo trato en http://olgacarreras.blogspot.com.es/2011/01/respuesta-25-dudas-habituales-sobre.html#301020092

Posadas de Venezuela dijo...
Este comentario ha sido eliminado por un administrador del blog.
Aunitz Giménez dijo...

Hola.
¡Excelente artículo! Como de costumbre.

Me ha llamado la atención que en la mala práctica 2 aconsejes limitar el maximum-scale a 2.0 para cumplir con el criterio de conformidad 1.4.4. Este criterio pide que al menos se permita ampliar el texto un 200%. Pero ¿por qué limitarlo a 200%? ¿Sería incorrecto no ponerle un límite al maximum-scale?

Olga Carreras dijo...

Hola Aunitz, es correcto no poner límite.

Quería ejemplificar que un límite a uno es incorrecto, pero un límite a 2, según las WCAG 2.0, no lo sería.

Isaac Palacio dijo...

Hola Olga,

Me gustaría saber si puedo conseguir este articulo en formato PDF, para llevarlo en mi e-reader, gracias.

Olga Carreras dijo...

Puedes imprimirlo como PDF

Marisol dijo...

Hola Olga, según la buena práctica nº 3, es importante que se siga visualizando el foco, pero es obligatorio el cumplimiento del criterio 2.4.7 en la web móvil, o en una web que vaya a verse según un diseño responsive. Gracias

Publicar un comentario en la entrada