Buenas prácticas para la web móvil 1.0

Se anima a los proveedores a ser sensibles con las necesidades del Contexto de Distribución por Defecto, esto no significa que el resultado sea una experiencia más pobre en dispositivos más capaces. Desarrollar sitios que tengan como entrada el Contexto de Distribución por Defecto. Además, donde sea apropiado, usar las capacidades de los dispositivos para dar una mejor experiencia de usuario en dispositivos más capaces.

Al igual que en el mundo de los ordenadores de sobremesas, hay navegadores que no respetan las intenciones de los proveedores de contenidos. Hay diferencias en las interpretaciones entre los navegadores y además hay deficiencias en la implementación. Por deficiencia queremos decir que no soportan unas características obligatorias de stándars relevantes o recomendaciones y errores o equivocaciones en la implementación.

Debido a que el software en los dispositivos móviles frecuentemente está incrustado en el dispositivo, no hay una manera fácil para corregir o arregralo una vez. Es un reto particular dar un entorno de trabajo para estas deficiencias o interpretaciones diferentes. Hay que reconocer que los proveedores de contenido han de violar

Buenas Prácticas específicas para soportar sus intenciones en los dispositivos que exhiben deficiencias en la implementación. Si un dispositivo es conocido por tener unas limitadas especificaciones entonces los proveedores de contenido deben completarlas con las Buenas Prácticas.

No es la intención recomendar un enfoque con un común denominador, ni tampoco es la intención recomendar evitar características que den problemas en una clase de dispositivos.

Tampoco es la intención sugerir que los proveedores de contenido restrinjan su soporte a cierto tipo de dispositivos. Los proveedores de contenidos deberían soportar un amplio rango de dispositivos

Un sitio Web debería de ser probado en un rango de navegadores. Los navegadores para móviles a menudo muestran características que son diferentes a los navegadores Web. Así como se evalúa la idoneidad de la visualización en un formato reducido, se les anima a los proveedores de contenido que prueben las características que ellos tienen en cuenta en el trabajo en los dispositivos actuales.

Los proveedores de contenido deberían probar además con características específicas deshabilitadas, como usar el modo sólo texto y con scripting deshabilitado.

Muchos fabricantes ofrecen emuladores para sus dispositivos que pueden suministrar un conveniente y preliminar modo de pruebas. Sin embargo, en la práctica, muchos de los emuladores se comportan de manera diferente a los dispositivos que emulan. Consecuentemente las pruebas se deberían llevar a cabo en un amplio rango de dispositivos reales y en versiones específicas de software como se hace en la práctica.

Teclear las URIs en dispositivos móviles puede ser difícil y se espera que los usuarios prefieran usar métodos alternativos para obtener las URIs cuando están disponibles- como seguir un hiperenlace (desde un e-mail, SMS o una página Web), WAP pus, código de barra en 2D, código de barras, etiqueta RFID y Bluetooth. Sin embargo, teclear una URI puede ser en algunos casos la única opción disponible. Haciendo que las URIs sean cortas es posible reducir la casualidad de error y dar una experiencia más satisfactoria al usuario.

Cuando se accede a un sitio los usuarios no deberían de tener que meter el nombre del fichero como parte de la URI. Si es posible, configura los sitios Web de tal manera que se pueda acceder sin tener que especificar un subdominio como parte de la URI.

Ejemplo: En lugar de requerir que los usuarios tecleen

"http://www.example.org/index.html"

permitir

"http://example.org"

y en lugar de

"http://www.example.org/example.html"

permitir

"http://example.org/example"

Ofrecer enlaces básicos en una sóla línea.

El diseño debería dirigirse a ofrecer un balance entre tener un gran número de enlaces de navegación en una página y la necesidad de navegar entre muchos enlaces para alcanzar el contenido.

El desplazamiento o scrolling en una página cuando hay muchos enlaces puede ser muy incómodo cuando la acción de navegación en muchos dispositivos móviles selecciona cada enlace en el sentido del desplazamiento o scrolling. Por otro lado, cada recuperación de la navegación de la página lleva tiempo y añade coste, así el número de enlaces en una página no debería de minimizarse a expensas de añadir recuperaciones de páginas.

Diseñar el servicio de manera que la información a la que más frecuentemente se accede sea fácilmente alcanzable con un mínimo número de recuperaciones de páginas. La navegación para llegar a información con menos accesos puede llevar tantas recuperaciones como obtener un resultado. Una guía para saber si los usuarios se están frustrando es cuando tienen que hacer más de 4 recuperaciones para alcanzar su objetivo. Si éste puede ser alcanzado depende de la naturaleza del sitio y particularmente de cómo los ítems están agrupados en menús para dar comprensión temática.

Usar los mismos mecanismos de navegación a través de los servicios de ayuda al usuario les orienta a los mismos y les permite identificar los mecanismos de navegación más fácilmente.

Los usuarios de dispositivos que no tienen apuntadores de dispositivos tienen que desplazarse entre los hiperenlaces usando teclado numérico. Agrupaciones inteligentes, quizás optimizada a través de una adaptación acorde al uso de patrones, puede ayudar a la usabilidad .

Un método "drill-down" (navegación inteligente), basado en importantes encabezados, puede dar a menudo un efectivo sentido a la navegación; debido a la colocación alineada de contenido, pequeño tamaño de pantalla y falta de puntero en el dispositivo, es a menudo útil dar un medio para saltar secciones enteras de contenido.

Cada entrada del enlace de subida de la navegación drill-down debería permitir al usuario saltar hacia arriba una sección entera .

Donde no hay un apuntador en el dispositivo, asignar una tecla de acceso a un enlace puede ser una manera conveniente para los usuarios de acceder al enlace y evitar navegar a un enlace presionando repetidamente una tecla de navegación.

Dar la misma clave de acceso a los enlaces que se repiten en las páginas como son los enlaces a las páginas de inicio.

Prueba automática: Probar la presencia del atributo accesskey

Prueba manual: Verificar la presencia del atributo accesskey en los enalces tales como la página de inicio.

Los usuarios de los dispositivos móviles sufren retraso excesivo y un coste como resultado de enlaces seguidos. Es importante identificar hacia donde el enlace se dirige de manera que los usuarios puedan hacer una evaluación de si continuando estarían interesados en ellos. Es improbable que el coste en términos monetarios de un usuario siguiendo un enlace particular pueda especificarse, debería ser posible dar una idea del tamaño del recurso (en bytes o de una manera abstracta, por ejemplo: tamaño del fichero)

Los enlaces a contenido que está en un diferente formato o diferente lenguaje a la página del enlace (por ejemplo: contenido que sólo puede ser interpretado por otras aplicaciones o descargas) deberían estar señalizados, de manera que los usuarios no tengan que bajarse el contenido que puede que no esté disponible para su uso. Sin embargo hay que tener presente que algunos dispositivos soportan la interpretación de estos formatos por aplicaciones una vez descargadas (ejemplo ficheros de música). Además, los usuarios pueden desear bajarse el contenido más tarde pasarlo a otros dispositivos completamente. Así incluso si es conocido que el agente del usuario no soporta un tipo de contenido particular, ese contenido debería todavía estar disponible.

Usa una clara, concisa y descriptiva línea de texto para ayudar a los usuarios a decidir si seguir un enlace. Identifica las implicaciones de seguir un enlace si la entrada es larga y el usuario no se anticipa desde el contexto.

Prueba manual: Chequear las descripciones (ejemplo: no usar "Pinchar aquí").

Prueba automática: Chequear los enlaces de los formatos no-HTML

Prueba manual: Chequear si hay información sobre el formato del enlace de destino.

Los mapas de imágenes permiten una navegación rápida siempre que la petición al dispositivo pueda soportar la complicada imagen y que exista un medio de navegación en el mapa satisfactorio. Arriba, abajo, derecha, izquierda y enter están disponibles en la mayoría de los dispositivos móviles, incluso si no hay puntero (apuntador) en el dispositivo. Esto es normalmente suficiente para permitir la navegación en partes activas de los mapas de imágenes en el cliente donde están definidas como formas geométricas.

Muchos dispositivos móviles carecen de un puntero y los mapas de imágenes del servidor no pueden ser usados en estos dispositivos.

Si solo imágenes pequeñas se pueden visualizar, romper las imágenes grandes en pequeñas secciones y repartirlas separadamente.

Pruebas automáticas de MAPAS_IMAGENES : Envía una petición al sitio con un dispositivo que no soporta el mapa de imágenes en el lado cliente y chequea el elemento map element is not present.

Cada una de estas actividades suele confundir a los usuarios, o añadir coste o retrasos a sus interacciones.

Algunos dispositivos móviles utilizan una ventana diferente para realizar las entradas de datos; esta sección no se refiere a esas ventanas.

Muchos dispositivos móviles no soportan que se puedan abrir varias ventanas a la vez y esto implica que si lo hacemos no podremos predecir lo que pasará.

El refresco automático de las páginas presenta problemas de accesibilidad. En el entorno de los dispositivos móviles, exponen al usuario a tener gastos innecesarios debido a que la página se vuelve a cargar completamente sin avisarle. Si la aplicación necesita utilizar refresco automático, siempre se debe proporcionar una forma de pararlo y se debe informar al usuario de que la página se actualizará y que esto puede suponerle un mayor coste.

Aunque la redirección es un mecanismo empleado comúnmente, se debe recordar que normalmente requiere un viaje de ida y vuelta en el navegador.

Esto añade retrasos en los enlaces lentos; así que se debe utilizar como mucho una redirección por página y limitar el número de páginas que son redirigidas

VENTANAS_EMERGENTES Prueba automática: Mira el atributo target en los enlaces y si lo tiene comprueba que su valor es diferente a _self, _parent o_top.

REFRESCO_AUTOMÁTICO Prueba automática: Comprueba si se utiliza meta http-equiv="refresh" content="<la misma URI>"

REFRESCO_AUTOMÁTICO Prueba manual: Si se utiliza refresco automático, comprueba que se proporcionan opciones para pararlo.

REDIRECCIÓN Prueba automática: Comprueba si se utiliza meta http-equiv="refresh" content="<una URI diferente>" .

Cada recurso (imágenes, hojas de estilo y otros objetos) requiere una petición diferente a través de la red. Esto puede añadir mucho tiempo para cargar la página en el contexto de los dispositivos móviles.

Prueba automática: Cuenta el número de imágenes, hojas de estilo y otros recursos utilizados.

Prueba manual: Revisar si se podría conseguir un efecto similar utilizando menos recursos.

Prueba manual: Examinar el contenido para determinar si el tema tratado es apropiado en el contexto móvil.

Si las páginas son muy grandes se tarda mucho tiempo en cargarlas. Además, los dispositivos móviles suelen tener restricciones sobre cual es el tamaño máximo de página que pueden cargar.

Por otra parte, si las páginas son demasiado pequeñas el usuario deberá realizar muchas peticiones para leer la información que le interesa. Esto puede provocar un retraso innecesario, ya que cada petición suele llevar bastante tiempo.

El balance entre la paginación y el desplazamiento vertical en una misma página es, en parte, una cuestión de gusto y en parte una necesidad. Los dispositivos que tienen muchas restricciones de memoria sólo pueden abrir páginas pequeñas. Al igual que otros dispositivos presentan una mala experiencia cuando el usuario se debe desplazar verticalmente y una mejor experiencia cuando se divide la información en diferentes páginas.

TAMAÑO_USABLE Prueba automática: Medir el tamaño total del lenguaje de marcas de la página; asegurarse que no sea superior a 10 kilobytes para el Contexto de Distribución por defecto.

Prueba manual: Asegurarse que la página sigue siendo usable (e.j. no cortar en mitad de una sentencia, justo antes del final de una sección, y en casos similares).

TAMAÑO_LIMITADO Prueba automática: Medir el tamaño total del lenguaje de marcas y de las imágenes de la página; asegurarse que no se superan 20 kilobytes para el Contexto de Distribución por defecto.

La página se debe presentar de tal manera que el scroll vaya en dirección vertical permitiendo que el usuario pueda tener una buena experiencia en todo el contenido. Sin embargo algún tipo de contenido (como mapas e imágenes) no puede ser visto sin utilizar el scroll secundario (horizontal).

Si un elemento de la página necesita el scroll secundario no se debe hacer que el resto de la página lo requiera. Por ejemplo, si un objeto tiene un margen significativo a su izquierda, el texto puede dejar de ser visible una vez que el usuario mueva el scroll y se pase el objeto.

De la misma forma, si la presencia de un objeto provoca que un texto aparezca más allá del margen derecho de la página el usuario necesitará el scroll para leer cada línea de texto.

Si no es posible evitar poner imágenes que sean más grandes que la pantalla, entonces se debe considerar poner esas imágenes en una página diferente con un enlace que lleve al contenido principal.

SCROLLING (DESPLAZAMIENTO) Prueba automática: Asegurarse de que el atributo width y las propiedades de estilo del ancho de la página es más ancho que la pantalla - para el Contexto de Distribución por defecto, 120 píxeles.

Prueba manual: Si es más ancho que la pantalla, comprobar que el caso del uso lo autorice (e.j. mapas).

SCROLLING_LIMITADO (DESPLAZAMIENTO_LIMITADO) Prueba manual: Mirar URIs dentro de un sitio con un dispositivo móvil y observar que en las páginas con elementos que requieren scrolling secundario sólo lo tienen los elementos que lo requieren, y el resto de la página sólo tiene scroll principal.

Muchas páginas Web están diseñadas con los elementos navegacionales y otros elementos significativos en la parte superior o lateral de la página (e.j. Barras de Menú, Rutas de Migas de Pan y Funciones de Búsqueda). Esto proporciona una metáfora navegacional conveniente en páginas grandes. Sin embargo, en páginas pequeñas esto puede dar lugar a que aparezca la barra de navegación en vez del contenido principal cuando se carga la página por primera vez.

Porque es importante que el usuario tenga una idea del contenido principal de la página la primera vez que la ve, debe ponerse la mínima información posible delante de lo principal - incluyendo navegación, imágenes decorativas, anuncios y otro material que no sea principal para la experiencia del usuario en la página. El usuario no debe tener que mover la barra de scroll para encontrar el contenido principal de la página.

Los menús de selección pueden ponerse en un lugar que no sea la parte superior de la página y poner un enlace que lleve al menú en su lugar. Alternativamente, se pueden utilizar enlaces con texto simple para ir a las mayores secciones del sitio Web.

Prueba manual: Mirar URIs dentro de un sitio utilizando un dispositivo móvil y observar que la información más importante/relevante aparece primero.

El mecanismo popular de utilizar un gráfico de 1 píxel para el posicionamiento absoluto no funciona en diferentes pantallas.

Los gráficos que son más grandes de lo necesario, por ejemplo para tener una mayor resolución que lo que el dispositivo puede mostrar o teniendo demasiados colores, malgastan ancho de banda.

GRÁFICOS_PARA_ESPACIOS Prueba automática: Comprobar los gráficos que sean muy pequeños y/o transparentes.

GRÁFICOS_GRANDES Prueba automática: Comprobar la dimensión de los gráficos.

A menudo los dispositivos móviles no tienen mucho contraste del color y se utiliza en unas condiciones de luz malas. Por lo tanto, la información que aparece resaltada en color puede no ser vista por los usuarios. Si el color utilizado indica una característica, también se deberá resaltar dicha característica de alguna forma que no sea dependiente del color. En particular, no se debe utilizar texto azul o morado, ya que se puede confundir con enlaces, especialmente en dispositivos en los que los enlaces no aparecen subrayados.

USO_DEL_COLOR Prueba manual: Ver la página en un entorno en blanco y negro.

CONTRASTE_DEL_COLOR Prueba manual: Ver la página bajo una luz fuerte paralela a la pantalla.

Prueba automática: Existen herramientas automáticas para comprobar el contraste del color.

El uso de imágenes para el fondo de la pantalla puede llevar a hacer que sea difícil ver el contenido principal de la página, especialmente debido al poco contraste que suelen tener los dispositivos móviles y a las malas condiciones en las que se suelen utilizar estos dispositivos.

Antes de utilizar imágenes de fondo, se debe considerar cuidadosamente los objetivos de hacerlo y se deben probar técnicas alternativas para conseguir objetivos similares. Si utilizas una imagen de fondo debes asegurar que el contenido se pueda leer con o sin la imagen para los dispositivos que no la soporten.

Prueba automática: Probar si hay una imagen de fondo o no.

Prueba manual: Probar si el contenido de la página se puede leer tanto en los dispositivos que soportan la imagen de fondo como en los que no la soportan.

Proporcionar un título descriptivo para la página que permita identificarla fácilmente. Se debe tener un título corto para reducir el tamaño de la página, y considerar que puede ser cortado.

Muchos navegadores móviles no muestran el título de la página. Donde se muestra el título el espacio puede ser limitado.

El dispositivo puede utilizar el título de la página como una etiqueta por defecto para los favoritos. Una vez más, el espacio puede ser limitado, así que puede ser utilizado para identificar el contenido y no para otros propósitos.

Prueba automática: Comprobar la presencia del atributo title.

Prueba manual: Comprobar que el título describe el contenido.

Muchos dispositivos móviles no soportan marcos. Además, los marcos generalmente causan problemas.

Prueba automática: Probar la presencia de marcos - probar los atributos frameset y iframe.

Es una buena práctica para todo indicar la estructura del documento mediante cabeceras y sub-cabeceras. Utilizando las etiquetas para indicar la estructura, mejor que efectos de formato, permite adaptar el contenido de una manera más fácil en los lugares en los que se necesita dividirlo en varias páginas, también facilitar el acceso a las secciones del documento en las que el usuario este interesado.

Donde se utilicen cabeceras se debe hacer de forma correcta de acuerdo con la especificación, e.j. deben ser jerarquizados correctamente según su nivel.

Los lenguajes de marcas como el HTML contienen muchas formas para indicar la estructura.

Las tablas no funcionan bien en pantallas cuyo tamaño está limitado y pueden provocar que el usuario deba utilizar el scroll horizontal para leerlas. Si se ponen los enlaces navegacionales dentro de una tabla, será necesario utilizar tanto el scroll vertical como el horizontal para hacer posible la navegación.

TSOPORTE_DE_TABLAS Prueba automática: Mandar una petición al sitio desde un dispositivo que no soporte tablas y verificar que el elemento table no está presente.

Prueba automática: Verificar que no haya tablas jerarquizadas.

TABLAS_PARA_DISPOSICIÓN Prueba automática: Verificar que ninguna columna ni fila de la tabla está vacía o contiene una imagen transparente de tamaño 1x1
Prueba automática: Si el elemento table está presente, se debe verificar que el contenido se vea de forma correcta fuera de dicho elemento. Si no es así, es probable que la tabla este siendo utilizada para establecer la disposición.

ALTERNATIVAS_PARA_ELEMENTOS_SIN_TEXTO Prueba automática: Comprobar la presencia del atributo alt imágenes y el contenido textual de objetos.

Prueba manual: Comprobar la importancia del significado del contenido del elemento alt.

OBJECTOS_O_SCRIPT Prueba automática: Comprobar la presencia de los elementos object o scripten el contenido mostrado en los dispositivos que no lo soporten.

Prueba manual: Si está presente, comprobar que la experiencia del usuario es aceptable.

Las imágenes como las bitmaps tienen un tamaño intrínseco. Decirle al navegador cual será el tamaño por adelantado con el fin de evitar que tenga que reordenar la página cuando las reciba. Cambiar el tamaño de las imágenes en el servidor reduce la cantidad de datos transferidos y lo que debe procesar el dispositivo para escalar la imagen.

ESPECIFICAR_EL_TAMAÑO_DE_IMAGEN Prueba automática: Comprobar la presencia de los atributos width y height en los elementos img.

CAMBIAR_EL_TAMAÑO_DE_LA_IMAGEN Prueba automática: Comprobar que los atributos width y height son iguales a las dimensiones de la imagen.

Si el documento no es válido la presentación será impredecible y posiblemente incompleta.

Prueba automática: Validar los documentos.

Usar porcentajes y medidas relativas como em, ex, bolder, larger y thick.

Prueba automática: Mandar una petición al sitio Web con un dispositivo que soporte medidas relativas correctamente y comprobar que los valores de font-size no son absolutas ni píxeles.

La información del estilo debe estar en una hoja de estilo que se relacione con la página mediante un enlace o, en el HTML, puede aparecer en un elemento de estilo o en el atributo de estilo de elementos específicos.

Los dispositivos móviles ofrecen diferentes formas de soporte para las hojas de estilo. Algunas proporcionan implementaciones completas, incluyendo cacheo de hojas de estilo externas; algunos no tienen cacheo externo de hojas de estilo; algunos no soportan el elemento style ; algunas implementaciones no soportan más de una hoja de estilo y algunos no soportan las hojas de estilo de ninguna forma.

Si las hojas de estilo no están activadas o no se soportan, el contenido se mostrará según el orden del documento, así que es importante que el contenido esté ordenado de una forma coherente.

USO_DE_HOJAS_DE_ESTILO Prueba automática: Mandar una petición al sitio Web con un dispositivo que soporte CSS y comprobar que se utiliza la hoja de estilo y que la página no utiliza etiquetas para representar el formato de la misma (e.j.font).

SOPORTE_DE_HOJAS_DE_ESTILO Prueba manual: Deshabilitar la hoja de estilos y comprobar que la página se sigue viendo correctamente.

TAMAÑO_DE_HOJAS_DE_ESTILO Prueba automática: Comprobar que se hace referencia a los elementos de la hoja de estilo al menos en una página.

El contenido que se crea utilizando lenguajes de marcas como XML a menudo puede ser más pequeño y se conserva exactamente la misma semántica simplemente quitando los espacios en blanco redundantes (e.j. espacios y nuevas líneas).

Es improbable que los autores tengan que crear su contenido en una única línea para quitar todos los espacios en blanco, pero no obstante se sugiere que los autores no aumenten el tamaño de las páginas insertando espacios en blanco innecesarios. Se debe tener en cuenta que un "formato bonito" (formatear el código con indentación) puede generar muchos espacios en blanco y por lo tanto aumentar mucho el tamaño de la página.

Si el "formato bonito" es una parte importante para el desarrollo del autor, se debe intentar quitar los espacios en blanco redundantes cuando se vaya a servir la página.

Aun cuando algunos proxies de la red eliminan los espacios en blanco que creen que son redundantes, no pasa con todos, por lo que no es una buena idea confiar en ello.

Prueba automática: Contar el número de espacios en blanco del documento que no sean significativos.

Transferir contenido que el dispositivo no puede mostrar hace que el usuario pierda tiempo y dinero. Un dispositivo puede expresar cuales son sus formatos preferidos. En este caso es una buena práctica respetar las preferencias del dispositivo, de la manera en la que se implementen estos formatos de una forma más completa.

Para determinar que formatos soporta el dispositivo, los sitios Web pueden utilizar una combinación del perfil del dispositivo como la cabecera HTTP de agente de usuario, la cabecera de aceptación http y UAProf.

Hay problemas con usar cualquier acercamiento a la exclusión de los otros. Algunos temas que han sido observados por el BPWG en este contexto son:

• Algunos dispositivos no proveen cabeceras de aceptación;

• Algunos dispositivos manejan de manera no adecuada los estados de sus capacidades;

• Algunas entradas de operador complementan las cabeceras de aceptación para incluir formatos que ellos adaptan;

• Los agentes de cabeceras no identifican siempre el dispositivo de forma única;

• La información UAProf puede no estar disponible o puede estar incompleta;

SOPORTE_PARA_EL_FORMATO_DE_LOS_CONTENIDOS Prueba automática: Comprobar los tipos MIMES del contenido desde varios dispositivos.

FORMATOS_PREFERIDOS Prueba automática: Comprobar los tipos MIME desde varios dispositivos y comprobar que se envía con el formato preferido por el dispositivo o que el formato es compatible con el Contexto de Distribución por defecto.

Como en la sección anterior, el contenido no se debe enviar al dispositivo si éste no puede utilizarlo.

Se pueden obtener las codificaciones del carácter que soportan los dispositivos a partir del perfil del dispositivo o examinando el valor de la cabecera HTTP Accept-Charset.
Se debe indicar que codificación del carácter se ha utilizado en la cabecera HTTP Content-Type de cada respuesta.

Ejemplo:
Content-Type: text/html; charset=utf-8

Prueba automática: Comprobar que se ha declarado el tipo de codificación y que es soportada. El tipo del contenido se puede declarar de una o varias de las siguientes maneras: cabecera Content-Type HTTP, declaración XML para contenido basado en XML, las reglas @charset de CSS, el elemento de HTML Content-Type Meta.

Es inevitable que, en ocasiones, un usuario no encuentre el contenido o la información que busca de forma satisfactoria. Es muy importante proporcionar una navegación sencilla particularmente en el mundo móvil, donde los navegadores no tienen el botón "atrás" muy accesible, donde frecuentemente la contextualización es difícil y donde la reentrada de URIs como medio para la recuperación de errores es particularmente difícil.

Se debe tener en cuenta que el proveedor del contenido no tiene el control sobre los errores de la red, la conexión y algún tipo de error al escribir las URIs, ya que no tiene ninguna manera de influir sobre este tipo de errores que se le presentan al usuario. Sin embargo, para los problemas que puedan ocurrir y que el desarrollador pueda controlar se le debe mostrar de forma clara cual es el problema. Esto ayuda a saber si el problema es temporal o permanente, si deben volver a intentar acceder al contenido y cómo pueden escalar el problema.

Se debe permitir que el usuario pueda salir del lugar donde se produjo el error. Debe poder volver a la página en la que se produjo el error, o poder moverse adelante hasta encontrar un lugar que funcione correctamente desde donde se pueda reintentar o alterar lo que se estaba intentando hacer.

Escribir una URI extraña, que se sepa que no es un recurso real del sitio Web, y comprobar que el error http 404 viene acompañado con una página cuyo lenguaje de marcas es apropiado para el dispositivo que realizó la petición, o el contexto por defecto.

Prueba manual: Comprobar que la página que se devuelve contiene una explicación del error y las acciones correctivas apropiadas, sin asumir ningún conocimiento técnico por parte del usuario.

Las cookies se utilizan frecuentemente para manejar la sesión, para identificar usuarios y para almacenar sus preferencias. Muchos dispositivos móviles no implementan cookies u ofrecen una implementación incompleta. Además, algunas pasarelas las eliminan y otros las simulan en parte de los dispositivos móviles.

Probar si el dispositivo soporta las cookies en la ruta de acceso actual. Si no las soporta, usar completitud de la URI para manejar la sesión, teniendo cuidado en no superar la longitud máxima del dispositivo para las mismas. Algunas pasarelas proporcionan la identificación del usuario sin configurar las cookies.

Prueba automática: Buscar una alternativa a las cookies para manejar la sesión cuando no sean soportadas.

El ancho de banda limitado y la gran latencia pueden reducir la usabilidad de los sitios Web en los dispositivos móviles. Si se utiliza la información de caché de forma efectiva se puede reducir la necesidad de recargar los datos como las hojas de estilo, las imágenes y las páginas, mejorando el funcionamiento y reduciendo el coste. También se puede prevenir la reutilización del contenido en donde no sea apropiado, por ejemplo el contenido que se adapta a un dispositivo puede que no se deba reutilizar por diferentes dispositivos. Las cachés de los dispositivos y de la red están afectadas por la información de cacheo.

Estable los tiempos para que expire la caché de tal manera que sea apropiado para tu aplicación. Considera utilizar Cache-Control: public para permitir compartir páginas entre dispositivos, Cache-Control: private para permitir reutilizar pero sólo cuando el dispositivo lo pida y Cache-Control: nocache para prevenir el cacheo.

Prueba automática: Comprobar la presencia de las cabeceras de caché en las respuestas HTTP.

Prueba automática: Comprobar la presencia de fuentes relacionadas con el estilo en un entorno en el que no sean soportadas.

Prueba manual: Si están presentes, asegurarse que queda clara la intención del autor.

Debido a las limitaciones típicas de los dispositivos móviles para la entrada de datos, en la interfaz se deben minimizar en lo posible las entradas de los usuarios. Cuando sea posible, hay que usar listas de selección, radio botones y otros controles con los que no se requiera que el usuario escriba.

Hay un grupo de técnicas disponibles para esto, entre las que se encuentran las siguientes:

• Cuando sea posible se deben utilizar las últimas entradas como entradas por defecto.

• Se debe hacer posible seleccionar ítems utilizando teclas de navegación y/o entrada numérica.

EVITAR_TEXTO_LIBRE Prueba automática: Comprobar si se utiliza input type="text" y textarea.

Prueba manual: Si se utiliza uno de ellos, comprobar si se puede reemplazar por una entrada predeterminada.

PROPORCIONAR_VALORES_POR_DEFECTO Prueba automática: Comprobar si hay un valor preseleccionado en los controles (un conjunto de atributos seleccionados o marcados).

Prueba manual: Si no, comprobar si de podría poner un valor preseleccionado (e.j. la elección más común).

MODO_DE_ENTRADA_POR_DEFECTO Prueba automática: Mandar una petición con un dispositivo que soporte el atributo inputmode y si la respuesta es un lenguaje soportado por este atributo, comprobar que esta presente en los elementos input type="text" y textarea .

Es importante que mientras el usuario navega por la página, los diversos campos y objetos se presenten en un orden lógico, especialmente porque muchos de ellos no serán visibles a la vez que el elemento actual.

Utilizar el orden del documento para controlar la disposición de los elementos de la página y el orden de tabulación.

Prueba automática: Comprobar que el atributo tabindex tabindex no está presente o efectos de disposición que afecten al orden de la presentación.

Si el atributo tabindex está presente comprobar que todos los controles tienen índice de tabulación y que se utilizan de una forma consistente.

Prueba manual: Si está presente el atributo tabindex o hay efectos de disposición que puedan afectar al orden de la presentación, entonces comprobar que el orden es usable.

Esto significa que se debe utilizar el elemento label de HTML, o un elemento equivalente en otros lenguajes. Hay que asegurarse de que la etiqueta esté colocada en el sitio que le corresponde de manera que siempre se reconocerá que controles corresponden con cada etiqueta y se mantendrán juntos.

Prueba automática: Comprobar que se utiliza el elemento label en los formularios.

Prueba manual: Comprobar si las etiquetas están colocadas correctamente respecto a los controles del formulario.