sábado, 21 de marzo de 2015

Comparativa de buenas prácticas para el diseño web móvil (MWBP) y pautas de accesibilidad web (WCAG)


Que tu web sea "amigable" para con los dispositivos móviles es hoy en día una necesidad, no sólo porque cada vez más usuarios utilizan esos dispositivos para acceder a contenidos en la web (véase el informe Sociedad de la Información en España 2014, por ejemplo) sino que es ya una exigencia por parte de algunas compañías de motores de búsqueda e indización (es el caso, por ejemplo de Google). Para conseguirlo debemos seguir las buenas prácticas para el diseño web móvil y, quienes llevamos tiempo trabajando por y para la accesibilidad llevamos ventaja en ello. Según mis análisis por el mero hecho de tener experiencia en accesibilidad cubres ya el 70% de los requisitos para que tu web sea amigable con los dispositivos móviles.

La cuestión de la mejora de la indización y posicionamiento en estos días es ya crítica dado que, por ejemplo, Google ha decidido penalizar las web que no sean amigables con los dispositivos móviles y está enviado a los webmaster mensajes como el siguiente:

Captura de pantalla de un mensaje de parte de google advirtiendo al webmaster que su web contiene errores de usabilidad en móviles y le sugiere algunas herramientas y tutoriales que le ayudarán a corregirlos.
Captura de pantalla del mensaje enviado por Google a los webmasters



En el blog de Google "Web Masters Central Blog" se publicó la noticia indicando que, a partir del 21 de abril considerarán la amigabilidad para con dispositivos móviles en su cálculo para determinar el ranking en el que se posicionarán las páginas. Por tanto, si tu web no cumple con las buenas prácticas para el diseño web móvil no se presentará en los primeros lugares cuando un usuario haga una búsqueda de las palabras clave relacionadas con tu sitio.

Google ofrece a los webmasters una serie de tutoriales y herramientas para facilitarle aplicar esos criterios que facilitarán que su web se presente adecuadamente cuando el usuario utiliza un dispositivo móvil. Pero, ¿son esos criterios muy diferentes de los que venimos aplicando desde la perspectiva de la accesibilidad?. La respuesta es no, en absoluto. Es más, como decía, el 70% de ellos quedan cubiertos por la experiencia de aquellos que vengan aplicando las pautas de accesibilidad desde hace años.

En la siguiente tabla se presenta el análisis que he hecho sobre la equivalencia entre las buenas prácticas para la web móvil (MWBP, por sus siglas en inglés) y las pautas de accesibilidad para el contenido en la web (WCAG, por sus siglas en inglés).

Para el estudio he utilizado los siguientes documentos:


La tabla recoge las 60 pautas de buenas prácticas para la web móvil, pero lo hace presentando en primer lugar las 7 pautas que quedan totalmente cubiertas por las WCAG 2.0, en segundo lugar aquellas para las que posiblemente no habría que hacer nada o que quedan parcialmente cubiertas y que son 16 y, finalmente, las 40 que teóricamente no quedan cubiertas. Si las cuentas no salen es porque hay dos pautas repetidas (alternativas para contenido no textual e identificación de los enlaces) debido a que se presentan tanto en la columna que indica que quedan cubiertas como en la columna que indica que pueden estar parcialmente cubiertas por otros criterios de las WCAG 2.0, según el documento comparativo con las WCAG 2.0 anteriormente mencionado.

En cuanto a las WCAG 1.0, aparecen en la última columna y cubrirían total o parcialmente 37 de las pautas para la web móvil, lo que supone el 61%. Solamente 18 pautas para la web móvil no quedan cubiertas por ningún criterio, ni de la versión 1.0 ni de la versión 2.0; es decir, tan sólo un 30%.

Es de destacar que, comparando los documentos "From WCAG 2.0 to MWBP" y "From WCAG 1.0 to MWBP" resultan 13 los criterios de buenas prácticas para el diseño web móvil que quedan cubiertos sólo por las WCAG 1.0, un 22%, pero no por las WCAG 2.0. Es decir, aquellos que se han acercado al mundo de la accesibilidad después de 2008, han tenido que aprender a integrar en sus hábitos de diseño y desarrollo ciertas prácticas sólo a la luz de la compatibilidad con móviles, pero en cambio quienes llegaron antes ya tenían esos buenos hábitos.

He agregado, indicando mis iniciales (EGYRS) aquellos criterios que creo cubren totalmente o en parte lo requerido para la web móvil y que no se indican en los documentos comparativos anteriormente citados. Como resultado, serían 17 las pautas que quedan totalmente cubiertas por las WCAG, 15 las que posiblemente se cubrirían y 10 las que quedarían parcialmente cubiertas: lo que hace un total de 42 y supone el 70%.

En mi análisis he añadido los equivalentes para los criterios de las WCAG 1.0 existentes en la WCAG 2.0, aunque en algunos casos debidos a técnicas recomendables y no requeridas, por lo que algunos desarrolladores las desconocen, pero son habituales en aquellos con mayor experiencia en la accesibilidad. Así que, la diferencia no es tan grande y, precisamente en dichos añadidos es donde puede estribar el interés de mi análisis, porque según éste sólamente dos criterios de las WCAG 1.0 no tienen equivalente en las WCAG 2.0 que puedan cubrir lo solicitado por las buenas prácticas para la web móvil.

Resumiendo, quien conozca y venga aplicando las pautas de accesibilidad para el contenido web de antiguo, estará cumpliendo ya con el 70% de los criterios de buenas prácticas para la web móvil.


Equivalencia entre criterios de MWBP y WCAG.
Criterio MWBP Cubierta 2.0 Posible/ 2.0 Parcial/ 2.0 Cubierta 1.0
AUTO_REFRESH
No cree páginas que se autorrefrescan periódicamente, a menos que haya informado al usuario y proporcionado un modo de detener el refresco.
3.2.5 AAA - - 7.4 P2, 7.5 P2 y 10.1 P2
FONTS
No dependa del soporte a estilos para fuentes.
1.3.1 A - - 6.1 P1 y 11.2 P2
LINK_TARGET_ID
Identifique claramente el propósito de cada enlace.
2.4.9 AAA - - 13.1 P2
NON-TEXT_ALTERNATIVES
Proporcione un texto equivalente para cada elemento no textual.
1.1.1 A - - 1.1 P1, 3.1 P2, 6.2 P1,
STYLE_SHEETS_USE
Use hojas de estilo para controlar la presentación y disposición, a menos que sepa que el dispositivo no las soporta.
1.3.1 A - - 3.3 P2
TAB_ORDER
Cree un orden lógico de tabulación a través de enlaces, controles de formulario y objetos.
2.4.3 A - - 9.4 P3
USE_OF_COLOR
Asegúrese de que la información transmitida mediante el color está también disponivle sin color.
1.4.1 A - - 2.1 P1
BACKGROUND_IMAGE_READABILITY
Si usa imágenes de fondo asegúrese de que el contenido sigue siendo legible en el dispositivo.
- 1.4.3 AA y 1.4.6 AAA - 2.2 P2
COLOR_CONTRAST
Asegúrese de que las combinaciones de color de fondo y frente proporcionan suficiente contraste.
- - 1.4.3 AA y 1.4.6 AAA 2.1 P1 y 2.2 P2 para imágenes y P3 para textos.
CONTROL_LABELLING
Etiquete todos los controles de formulario adecuadamente y asocie las etiquetas explícitamente con sus controles.
- 1.3.1, 3.3.2, 4.1.2 A - 10.2 P2 y 12.4 P2
CONTROL_POSITION
Coloque las etiquetas de manera que adecuada en relación al control al que se refiere.
- 1.3.1 A - 10.2 P2 y 12.4 P2
GRAPHICS_FOR_SPACING
No utilice gráficos para crear espacios.
- 1.3.1 A - 3.1 P2
LINK_TARGET_ID
Identifique claramente el propósito de cada enlace.
- - 2.4.4 A 13.1 P2
MEASURES
No use medidas en px y no utilice medidas absolutas en los valores de los atributos del lenguaje de marcado y en los valores de ls propiedades de las hojas de estilo.
- 1.4.4 A - 3.4 P2
NAVIGATION
Proporcione mecanismos de navegación consistentes.
- - 3.2.3 AA y 2.4.10 AAA. EGYRS: 3.2.4 AA 13.4 P2
NON-TEXT_ALTERNATIVES
Proporcione un texto equivalente para cada elemento no textual.
1.1.1 A - EGYRS: 1.2.8 AAA y 1.2.9 AAA (En el documento de comparativa apunta a 1.2.7, pero eso es un error) 1.1 P1
PAGE_TITLE
Proporcione un título corto pero descriptivo para la página.
- 2.4.2 A - 13.2 P2
POP_UPS
No genere pop-ups o que se abran otras ventanas y no cambie la ventana actual sin advertirlo al usuario.
- 3.2.5 AAA 3.2.1 y 3.2.2 A 10.1 P2
REDIRECTION
No utilice el marcado para redirigir páginas automáticamente. En vez de ello, configure el servidor para llevar a cabo las redirecciones mediante códigos HTTP 3xx.
- 2.2.1 A, 2.2.4 y 3.2.5 AAA - 7.5 P2
STRUCTURE
Use las características del lenguaje de marcado para indicar la estructura lógica del documento.
- 1.3.1 A, 2.4.6 AA y 2.4.10 AAA - 3.5 P2
STYLE_SHEETS_SUPPORT
Organice los documentos de manera que si es necesario puedan ser leídos sin hojas de estilo.
- 1.3.1 A - 6.1 P1
VALID_MARKUP
Cree documentos válidos de acuerdo con las gramáticas formales.
- 4.1.1 A - 3.2 P2, 11.1 P2, y 11.2 P2
ACCESS_KEYS
Asigne atajos de teclado a los enalces de los menú de navegación y a las funcionalidades frecuentemente utilizadas.
EGYRS: 2.4.1 A (Técnica aconsejable) - - 9.5 P3
AVOID_FREE_TEXT
En lo posible, evite la entrada de texto libre.
- - - -
[BALANCE]
Tenga en cuenta el equilibrio entre tener demasiados enlaces en una página y pedir al usuario que siga demasiados enlaces para llegar a lo que están buscando.
- EGYRS: 2.4.5 AA - -
CACHING
Proporcione información de caché en las respuestas HTTP.
- - - -
CAPABILITIES
Aproveche las capacidades del dispositivo para proporcionar una experiencia de usuario mejorada.
- - - -
CENTRAL_MEANING
Asegúrese de que el material que es importante para el significado de la página precede al que no lo es.
EGYRS: 2.4.5 AA (G125 y G126) - - 13.5 P3
CHARACTER_ENCODING_SUPPORT
Asegúrese de que el contenido está codificado utilizando una codificación de caracteres que sabe que es soportada por el dispositivo.
- - - -
CHARACTER_ENCODING_USE
Indique en la respuesta la codificación de caracteres que se está usando.
- - - -
CLARITY
Use lenguaje claro y simple.
EGYRS: 3.1.5 AAA - - 13.8 P3 y 14.1 P1
CONTENT_FORMAT_PREFERRED
Cuando sea posible, envíe contenido en el formato preferido por el dispositivo.
- - - EGYRS: 11.3 P3
CONTENT_FORMAT_SUPPORT
Envíe contenido en un formato que se sepa será soportado por el dispositivo.
- - - EGYRS: 11.3 P3
COOKIES
No dependa de que las cookies estarán disponibles.
- - - -
DEFAULT_INPUT_MODE
Especifique un modo de entrada de texto por defecto, idioma y/o formato de entrada, si sabe que el dispositivo lo soporta.
- - - -
DEFICIENCIES
Siga pasos razonables para cubrir las deficiencias de implementación con soluciones temporales.
EGYRS: No por las WCAG pero es habitual tener que cubrir las deficiencias de los agentes de usuarios. - - -
ERROR_MESSAGES
Proporcione mensajes de error informativos y medios para salir de un mensaje de error de vuelta a la información útil.
- EGYRS: 2.1.2 A, 3.3.4 AA y 3.3.6 AAA - -
EXTERNAL_RESOURCES
Mantenga al mínimo el número de recursos externos enlazados.
- - - -
IMAGE_MAPS
No utilice mapas de imágen a menos que sepa con seguridad que el dispositivo lo soporta eficazmente.
EGYRS: 1.1.1 A, 2.1.1 A y 2.4.4 A - - 1.2 P1 y 9.1 P1
IMAGES_RESIZING
Maneje el tamaño de las imágenes desde el servidor, si tienen un tamaño intrínseco.
EGYRS: G146 para 1.4.8 AAA - - -
IMAGES_SPECIFY_SIZE
Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
- - - -
LARGE_GRAPHICS
No utilice imágenes que no podrán ser renderizadas por el dispositivo. Evite imágenes grandes o de alta resolución excepto cuando en otro caso se perdería información crítica.
- - - -
LIMITED
Limite el contenido a lo que el usuario ha solicitado.
EGYRS: 2.4.6 AA y 3.1.5 AAA - - 13.8 P3 y 14.1 P1
LINK_TARGET_FORMAT
Advirta sobre el formato de los ficheros enlazados a menos que sepa que el dispositivo lo soporta.
EGYRS: 2.4.4 A, y 2.4.9 AAA - - 11.3 P3 y 13.1 P2
MINIMIZE
Utilice el marcado de manera escueta y eficiente.
- - - -
MINIMIZE_KEYSTROKES
Mantenga al mínimo el número de pulsaciones de teclas.
- - - -
NAVBAR
Proporcione una barra de navegación mínima al inicio de la página.
- EGYRS: 2.4.5 AA - 13.5 P3
NO_FRAMES
No use marcos.
- - - -
OBJECTS_OR_SCRIPT
No dependa de objetos embebidos o scripts.
- - EGYRS: 1.1.1 A 6.3 P1, 6.5 P2 y 9.2 P2.
PAGE_SIZE_LIMIT
Asegúrese de que el peso total de la página es apropiado para las limitaciones de memoria del dispositivo.
- - - -
PAGE_SIZE_USABLE
Divida las páginas en porciones de tamaño limitado pero que resulten usables.
- - EGYRS: 2.4.10 AAA 12.3 P2
PROVIDE_DEFAULTS
Proporcione valores por defecto preseleccionados cuando sea posible.
- - - 10.4 P3
SCROLLING
Limite el desplazamiento a una dirección, a menos que no pueda evitarse un desplazamiento secundario.
- - EGYRS: 1.4.8 AAA -
STYLE_SHEETS_SIZE
Mantenga pequeñas las hojas de estilo.
- - - -
SUITABLE
Asegúrese de que el contenido es adecuado para su uso en un contexto móvil.
- - EGYRS: 2.4.6 AA 13.8 P3 y 14.1 P1
TABLES_ALTERNATIVES
Cuando sea posible, utilice una alternativa a la presentación mediante tablas.
- - EGYRS: 1.3.1 A y 1.3.2 A 5.3 P2
TABLES_LAYOUT
No use tablas para disponer el contenido.
EGYRS: 1.3.1 (Técnicas recomendadas) - - 5.3 P2, y 5.4 P2.
TABLES_SUPPORT
No use tablas a menos que sepa que el dispositivo las soporta.
- - - -
TABLES_NESTED
No use tablas anidadas.
Nota: falta en "From WCAG 2.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 2.0 also meet Mobile Web Best Practices"
- - - -
TESTING
Lleve a cabo pruebas en dispositivos reales y también en emuladores.
EGYRS: Conformidad y Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 - - -
THEMATIC_CONSISTENCY
Asegúrese de que el contenido que se proporciona al acceder a una URI produce una experiencia temáticamente coherente cuando se accede desde diferentes dispositivos.
- EGYRS: Pauta 3. - -
URIS
Mantenga cortas las URI de entrada al sitio.
- - - -

Criterios no cubiertos por la accesibilidad

Tras el análisis nos queda que los siguientes son los 18 criterios no cubiertos por las pautas de accesibilidad:

  • AVOID_FREE_TEXT: En lo posible, evite la entrada de texto libre.
  • CACHING: Proporcione información de caché en las respuestas HTTP.
  • CAPABILITIES: Aproveche las capacidades del dispositivo para proporcionar una experiencia de usuario mejorada.
  • CHARACTER_ENCODING_SUPPORT: Asegúrese de que el contenido está codificado utilizando una codificación de caracteres que sabe que es soportada por el dispositivo.
  • CHARACTER_ENCODING_USE: Indique en la respuesta la codificación de caracteres que se está usando.
  • COOKIES: No dependa de que las cookies estarán disponibles.
  • DEFAULT_INPUT_MODE: Especifique un modo de entrada de texto por defecto, idioma y/o formato de entrada, si sabe que el dispositivo lo soporta.
  • EXTERNAL_RESOURCES: Mantenga al mínimo el número de recursos externos enlazados.
  • IMAGES_SPECIFY_SIZE: Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • LARGE_GRAPHICS: No utilice imágenes que no podrán ser renderizadas por el dispositivo. Evite imágenes grandes o de alta resolución excepto cuando en otro caso se perdería información crítica.
  • MINIMIZE: Utilice el marcado de manera escueta y eficiente.
  • MINIMIZE_KEYSTROKES: Mantenga al mínimo el número de pulsaciones de teclas.
  • NO_FRAMES: No use marcos.
  • STYLE_SHEETS_SIZE: Mantenga pequeñas las hojas de estilo.
  • TABLES_SUPPORT: No use tablas a menos que sepa que el dispositivo las soporta.
  • TABLES_NESTED: No use tablas anidadas.
  • URIS: Mantenga cortas las URI de entrada al sitio.

Y de todas ellas hay unas cuantas que, aunque no se consideran requisitos para la conformidad, están cubiertas por lo que podríamos llamar buenas prácticas del diseño web sin más o de atención a ciertos grupos de personas con discapacidad. Por ejemplo, podríamos excluir de la lista:

  • AVOID_FREE_TEXT: En atención a personas con ciertas deficiencias cognitivas se suele facilitar texto por omisión o selectores con respuestas predefinidas que facilitan el rellenar un formulario a todos.
  • CHARACTER_ENCODING_SUPPORT: En general hoy en día se sigue la buena práctica de codificar en UTF8.
  • CHARACTER_ENCODING_USE: Esto lo hará el servidor.
  • LARGE_GRAPHICS: Al tener en cuenta usuarios con conexiones de banda estrecha se tiende a cuidar el peso de los elementos.
  • MINIMIZE_KEYSTROKES: Al igual que la primera va encaminada a ahorrarle al usuario tener que escribir, así que quedaría también cubierta por el buen diseño de formularios y campos de entrada.
  • MINIMIZE: Todos es cuestión de configurar el servidor o utilizar las herrameintas existentes para ello.
  • NO_FRAMES: Hace muchísimos años que casi nadie usa marcos y de todos es sabida la dificultad que presentan para los usuarios de lectores de pantalla.
  • TABLES_NESTED: Aunque no es un requisito para la conformidad, de siempre se ha alentado a simplificar las tablas dado los problemas que pueden suponer para algunos usuarios, máxime si están anidadas.
  • URIS: Sobre cómo deberían ser las URI, Tim Bernes-Lee escribió hace ya muchísimo tiempo, y desde luego nada que ver con esas direcciones larguísimas y supuestamente "amigables para el usuario" que generan alguns CMS y alientan algunos diseñadores. Ahora todo vuelve a su cauce.

Tendríamos 8 criterios más a agregar al saco de criterios cubiertos por la experiencia en diseño desde la perspectiva de la accesibilidad. Quedando, por tanto tan sólo un 17% de los criterios de buenas prácticas para el diseño web móvil sin cubrir. Es decir, los desarrolladores/diseñadores con experiencia en accesibilidad tienen en sus hábitos de trabajo ya lo necesario para cubrir el 83% de los criterios para que su web sea amigable con los dispositivos móviles.
Gráfica que presenta en forma de tarta el resumen de resultados: WCAG 1.0 + WCAG 2.0 = 40 ó 70%, sólo WCAG 1.0 = 2 ó 3%, sentido común = 8 ó 13%, no cubiertas = 10 ó 17%.
Gráfica de resultados del análisis



Criterios conflictivos

De los 10 criterios que no quedan cubiertos, hay 3 que me parecen conflictivos:

  • EXTERNAL_RESOURCES: Mantenga al mínimo el número de recursos externos enlazados.
  • IMAGES_SPECIFY_SIZE: Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • STYLE_SHEETS_SIZE: Mantenga pequeñas las hojas de estilo.

Cuando digo "conflictivos" me refiero a que pueden suponer, lo que algunos, para evitar aplicar los criterios de accesibilidad llaman "una carga excesiva". Naturalmente nadie va a reclamar que eso suponga una carga excesiva, Google manda y todos queremos estar en buenas relaciones con él. Pero el caso es que modificar una web existente para cumplir con esos cuatro criterios puede resultar en un gran dolor de cabeza. Sobre todo si se trata de una web muy antigua. Y es que, el primero supondrá modificar las cabeceras de todas las páginas, mientras que es posible que en nuestro antiguo sitio web tengamos una cabecera para todas ellas y desde allí estemos llamando a varios recursos útiles para el sitio en su conjunto y no sólo para una página en concreto. O definir en cada imagen el tamaño de la misma, cuando por razones, precisamente de adaptabilidad y compatibilidad con diversos tamaños de pantalla, no lo hemos hecho. O hacer lo que Google sugiere sobre las hojas de estilo en Optimize CSS Delivery, cuando ahí mismo advierte que pronto no será necesario utilizar javascripts, pues se podrá hacer mediante el elemento link y cuando el criterio 5.4.10 de las buenas prácticas para el diseño web móvil piden precisamente que "Use of structural markup (see 5.4.3 Structural Elements) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS" (el remarcado es mío). Y es más, algunos CMS combinan todos los estilos definidos en varias hojas de estilo (del tema, del autor, etc.) de manera que resulte una única hoja de estilos.