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 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:
- Mobile Web Best Practices 1.0 en el que se indican ya las equivalencias existentes con la versión 1.0 de las WCAG, aunque no de manera muy exacta;
- From WCAG 2.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 2.0 also meet Mobile Web Best Practices, que hace una coparativa entre las WCAG 2.0 y el documento precedente
- From WCAG 1.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 1.0 also meet Mobile Web Best Practices, para comparar con la información previa en el documento de las buenas prácticas y asegurar que estuvieran todos los criterios.
- Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order
- Web Content Accessibility Guidelines 1.0
- Web Content Accessibility Guidelines (WCAG) 2.0
- Techniques for WCAG 2.0, porque siempre hay alguna técnica poco conocida que cubre ciertas necesidades
- Understanding WCAG 2.0, porque muchas veces este documento ofrece una visión mucho más amplia que la que ofrece el documentos de las pautas de accesibilidad.
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.
| 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 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.
