lunes, 21 de mayo de 2012

Usabilidad e internacionalización

Internacionalización, localización, sitio multilingüe… Lo primero es aclarar la terminología porque no siempre se utilizan estos términos correctamente, o al menos de acuerdo a lo que el W3C entiende por cada uno de ellos. Esto puede llevar a equívocos cuando se analiza la documentación sobre internacionalización del W3C o se revisan otras referencias.

Internacionalización y localización

En el documento del W3C “Diferencias entre localización e internacionalización” se definen y acotan estos términos de manera muy clara.

Localización (o "l10n")
Es la adaptación de un producto, una aplicación o el contenido de un documento con el fin de adecuarlo a las necesidades lingüísticas, culturales u otras de un mercado destinatario concreto. 

Esta adecuación no es sólo traducirlo a otro idioma sino también tener en cuenta otro tipo de factores que implican adaptarlo en relación con:

  • diferentes formatos:
    • numéricos: por ejemplo separación de miles y decimales con coma o con punto
    • de fecha: por ejemplo "02/03/04" puede interpretarse de diferente manera en EEUU, Europa o Japón, como veremos luego; o incluso pueden utilizarse diferentes calendarios
    • de hora: formato 12 horas por defecto para EEUU o de 24 horas europeo; pero también puede ser necesario indicar respecto a qué uso horario hace referencia un horario concreto
  • diferentes monedas y símbolos de las mismas
  • diferentes medidas de distancia, temperatura, etc.
  • diferentes alfabetos, dirección de escritura o uso del teclado
  • diferentes tipos y formatos de tratamientos, nombres y apellidos, direcciones o teléfonos
  • los algoritmos de comparación y ordenamiento deben adaptarse al idioma, pero a veces también al país, por ejemplo en Islandia los directorios se ordenan por nombre de pila.
  • diferente significado y percepción de metáforas, símbolos, iconos y colores
  • los textos y gráficos que contengan referencia a objetos, acciones o ideas que, en una cultura dada, puedan ser objeto de mala interpretación o considerados ofensivos
  • diferentes exigencias legales
  • diferentes tamaños estándar de papel (relevante para la impresión)
  • etc.

Puede suponer incluso la reelaboración exhaustiva de la lógica, el diseño visual o la presentación según cada país y cultura.

Internacionalización (o "l18n")

La internacionalización es el diseño y desarrollo de un producto, una aplicación o el contenido de un documento de modo tal que permita una fácil localización (adaptación del contenido a diferentes idiomas, regiones o culturas según hemos visto anteriormente) sin necesidad de realizar cambios en el código.

Supone la utilización de formatos y protocolos que no establezcan barreras a los diferentes idiomas, sistemas de escritura, códigos y otras convenciones locales, aunque no hayamos llevado a cabo la localización del sitio. 

Garantizar la utilización universal de una web en todos los idiomas y culturas implica:

  • Un modo de diseño y desarrollo que elimine obstáculos a la localización o la distribución internacional: usar Unicode, controlar la concatenación de cadenas, evitar que la programación dependa de valores de cadenas pertenecientes a la interfaz de usuario, etc.
  • Habilitar características que tal vez no sean usadas hasta el momento de la localización: añadir en la DTD etiquetas para habilitar el texto bidireccional o la identificación de idiomas, hacer la CSS compatible con texto vertical u otras características tipográficas ajenas al alfabeto latino, etc.
  • Preparar el código para hacer frente a las preferencias locales, regionales, lingüísticas o culturales, como son los de formatos de fecha y hora, calendarios locales, formatos y sistemas de números, ordenamiento y presentación de listas, uso de nombres personales y formas de tratamiento, etc.
  • Separar del código o contenido los elementos localizables, de modo que puedan cargarse o seleccionarse alternativas localizadas según determinen las preferencias internacionales del usuario.

Más información en Guía breve de internacionalización

Monolingües versus plurilingües

También hay que distinguir los términos “internacional” y “plurilingüe”; el primero es un sitio destinado a un público internacional, y el segundo un sitio que está disponible en más de un idioma. Un sitio web internacional puede ser o no multilingüe, así como un sitio web multilingüe puede ser o no internacional.

Por ejemplo, podemos tener un formulario en el cual se indica un importe en euros, se solicita obligatoriamente dos apellidos y seleccionar de un desplegable una provincia, se pide el DNI, etc., si tal cual se traduce a varios idiomas, da igual que sea multilingüe, no es internacional. En cambio, si se tiene en cuenta a todos los posibles usuarios que pueden utilizar ese formulario, independientemente de su país de origen, será internacional aunque sólo esté disponible en un idioma.

Por tanto, un sitio web internacional presenta información a un público internacional. Y además se puede decidir un enfoque monolingüe o uno plurilingüe.

La decisión depende de los objetivos del portal y su target objetivo.

Es muy interesante al respecto el documento del W3C Sitios web monolingües versus plurilingües donde se indica que el enfoque que se elija dependerá de lo siguiente:

  • el tipo de material; por ejemplo, ¿es material técnico sencillo o material destinado a motivar o vender?
  • su público; por ejemplo, ¿es un grupo bien definido que se ajusta a estándares acordados o son lectores en general?
  • sus medios económicos y recursos; por ejemplo, ¿se puede lograr el enfoque preferido dentro del presupuesto, o es simplemente demasiado complejo o costoso mantener el negocio?

También debería considerar lo siguiente:

  • los requisitos para acceder a la información; por ejemplo, ¿los usuarios pueden entender sin traducción?
  • el impacto deseado en el lector; por ejemplo, ¿su intención es motivarlo, persuadirlo o entretenerlo?
  • lo pertinente o apropiado que sea a la situación de los usuarios; por ejemplo, ¿tiene que considerar diferentes hábitos de compra, precios, requisitos legales u otros diversos contextos sociales del público internacional?

Validador de Internacionalización del W3C

El W3C cuenta con un validador automático W3C Internationalization Checker. Es importante comprender que valida características de internacionalización de la página (no de localización, según la definición del W3C para cada término) asesorando además sobre cómo mejorar el uso del etiquetado en una web multilingüe.

Se puede ver un listado de todos los posibles errores en “Internationalization Checker reports”, algunos por ejemplo son:

  • Encoding declared only in HTTP header
  • The html tag has no language attribute
  • A tag uses a lang attribute without an associated xml:lang attribute (en XHTML)
  • Incorrect values used for dir attribute
  • etc.

Pautas para la internacionalización y localización de tu web

W3C

Las mejoras prácticas están resumidas en la tarjeta Internationalization Quick Tips for the Web (PDF) que se desarrolla con más detalle en Consejos rápidos sobre internacionalización para la Web.

Estos 10 consejos son:

  1. Codificación. Utilice Unicode siempre que sea posible para contenidos, bases de datos, etc. Siempre declare la codificación del contenido.
  2. Escapes. Utilice caracteres en lugar de escapes (por ejemplo, á á o á) siempre que sea posible.
  3. Idioma. Declare el idioma de los documentos e indique los cambios de idioma internos.
  4. Presentación vs. contenido. Utilice hojas de estilo para información de presentación. Restrinja el uso de etiquetas para la semántica.
  5. Imágenes, animaciones& ejemplos. Verifique si es posible la traducción y si existe alguna influencia cultural inadecuada.
  6. Formularios. Utilice una codificación adecuada tanto en el formulario como en el servidor. Admita los formatos locales de nombres/direcciones, horas/fechas, etc.
  7. Autoría de texto. Utilice texto simple y conciso. Tenga cuidado al componer oraciones de cadenas múltiples.
  8. Navegación. Incluya en cada página una navegación que pueda verse claramente hacia las páginas o los sitios localizados, utilizando el idioma de llegada.
  9. Texto de derecha a izquierda. Para XHTML, agregue dir="rtl" a la etiqueta html. Utilícela nuevamente sólo para cambiar la dirección de base.
  10. Verifique su trabajo. ¡Realice la validación! Utilice las técnicas, los tutoriales y los artículos que se encuentran en http://www.w3.org/International/

Para conocer a fondo las técnicas y buenas prácticas que recomienda el W3C podemos consultar dos referencias:

En primer lugar voy a comentar 4 buenas prácticas incluidas en la primera referencia, porque me parecen especialmente importantes. A continuación incluiré las 16 buenas prácticas del documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content

Cómo incluir la selección de idioma

Exponen todos los problemas asociados a que la selección de idioma se realice a través de un desplegable, e indican en qué condiciones puede ser práctico tener o no un enlace a una página de portal global para ello.

Pero si a pesar de todo utilizas un desplegable para seleccionar el idioma te dan una serie de recomendaciones: incluirlo en la esquina superior derecha, traducir cada opción a su idioma, cómo ordenar los valores del desplegable, etc.

Ver: Uso de <select> para enlazar contenido localizado

El tamaño del texto en la traducción

Los textos en inglés ocupan mucho menos que los textos en español. Según esta referencia, en función de la cantidad de caracteres que tenga un texto en inglés, en los idiomas europeos puede llegar a una expansión del 300%.

Por ejemplo “Set the power switch to 0” tiene 26 caracteres. En español “Ponga el interruptor de alimentación de corriente en 0" tiene 55 caracteres, es decir, un 112% más.

¿Están el diseño y la maquetación preparados para que un mismo texto pueda ocupar hasta un 300% más? Cuando un texto está sobre una imagen de fondo (por ejemplo sobre la imagen de fondo de una pestaña) ¿se podrá leer bien, sin cortes o desbordamientos, si se traduce ese texto a otro idioma en el cual ocupe más espacio?

Ver: El tamaño del texto en la traducción

Formatos de fecha

El formato de las fechas puede resultar confuso para aquellos que visitan un sitio web, hablan distintos idiomas y provienen de diferentes regiones.

En EEUU el formato es MM/DD/AA, pero en la mayoría de los países europeos (como España o Inglaterra) es DD/MM/AA, o en Japón es AA/MM/DD. Hay que ser consciente de que una fecha como 02/03/04 en Japón es 4 de marzo de 2002, en Europa 2 de marzo de 2004 y en EEUU 3 de febrero de 2004

Puede que nuestro sitio vaya a ser multilingüe y pensemos que ya se adaptará durante el proceso de localización en función del idioma. Sin embargo, esto no siempre resuelve el problema.

Es decir, si nuestro sitio está en español e inglés, ¿qué formato de fechas ponemos en la versión inglesa? No vamos a tener versiones distintas (para EEUU y para Inglaterra) sólo por los formatos de las fechas.

También puede ser que nuestro sitio esté sólo en un idioma, pero queremos asegurar su internacionalización, que sea lo más comprensible posible por todos los usuarios, independientemente de su idioma o procedencia.

El W3C propone varias alternativas:

  • usar el formato internacional (ISO 8601): AAAA-MM-DD, pero su desventaja más evidente es que no es amigable para el usuario
  • usar el formato “2 de abril de 2003”, cuyas principales desventajas es que ocupa más espacio y puede suponer más problemas para hacer ordenaciones cronológicas.
  • usar el encabezado HTTP Accept-Language, insertando un formato u otro (MM/DD/AA, DD/MM/AA, AA/MM/DD) dinámicamente según la configuración del navegador del usuario.

    Sin embargo hay ciertas consideraciones a tener en cuenta, como explican el documento. Por ejemplo, si estás en la versión en inglés y detectas que es un usuario japonés y pones el formato AA/MM/DD, este puede pensar que está viéndolo en el formato inglés MM/DD/AA.

    Sobre las preferencias que estableces en el navegador y que serán las que utilizará HTPP Accept-Language, se puede consultar: Setting language preferences in a browser

Por otra parte, si en un formulario se solicita una fecha en un único campo se debe indicar el formato requerido. Si se solicita mediante tres campos, se tiene que indicar qué dato (DD, MM, AAAA) se solicita en cada campo. También es muy útil poder seleccionar la fecha en un calendario.

En el caso de los horarios también habrá que tener en cuenta que deberíamos indicar si estamos utilizando un formato 12 horas o 24 horas, y en base a qué uso horario (si es pertinente).

Ver: Formatos de fechas y Fechas y horarios

Datos que se solicitan en un formulario

Cuando se definen los campos de un formulario, muchas veces no se tiene en cuenta si es un formulario en un sólo idioma pero que pueden rellenar personas de muy diferentes nacionalidades, o si es un formulario que tendrá diferentes versiones para diferentes idiomas.

Pero también hay que tener en cuenta que incluso si el sitio tiene versiones en diferentes idiomas, un mismo idioma es común a muchos países o culturas. O que por ejemplo un francés puede acceder a la versión en inglés si domina este idioma pero no el español (y no hay una versión en francés). O por ejemplo que la versión en español puede estar usándola una persona que vive en España pero es extranjera.

En este apartado se explican cosas como que en Islandia los directorios se ordenan por nombre de pila; que hay países en los que será correcto solicitar dos apellido pero en otros no; que en países como España una persona puede tener nombres compuestos (por ejemplo, María José Quiñones), por tanto diferenciando nombre y apellido en dos campos se podrá procesar automáticamente si debemos llamarla Sra. José o Sra. Quiñones; etc.

¿Qué implica todo esto en el diseño? Que debe ser flexible, y dan recomendaciones concretas como por ejemplo:

La solicitud de primer nombre, inicial de segundo nombre y apellido no es internacional

Ver: Personal names around the world

Como ya he comentado, en el documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content, 2007, se definen asimismo 16 buenas prácticas:

Best Practice 1: Using attributes in the html tag

Always declare the default language for text in the page using attributes on the html tag, unless the document contains content aimed at speakers of more than one language.

Best Practice 2: Using attributes in the html tag for multilingual audiences

Where a document contains content aimed at speakers of more than one language, decide whether you want to declare one language in the html tag, or leave the languages undefined until later.

Best Practice 3: Dividing multilingual documents

Where a document contains content aimed at speakers of more than one language, try to divide the document linguistically at the highest possible level, and declare the appropriate language for each of those divisions.

Best Practice 4: Identifying changes in language within the document

Use the lang and/or xml:lang attributes around text to indicate any changes in language.

Best Practice 5: Choosing between lang and xml:lang

For HTML use the lang attribute only, for XHTML 1.0 served as text/html use the lang and xml:lang attributes, and for XHTML served as XML use the xml:lang attribute only.

Best Practice 6: Choosing between Content-Language and attributes

Use language attributes rather than HTTP or meta elements to declare the default language for text processing.

Best Practice 7: Using the body tag

Do not declare the default language of a document in the body element, use the html element.

Best Practice 8: Handling attribute values and element content in different languages

If the text in attribute values and element content is in different languages, consider using a nested approach

Best Practice 9: Using HTTP or a meta tag to indicate audience

Consider using a Content-Language declaration in the HTTP header or a meta tag to declare metadata about the language(s) of the intended audience of a document.

Best Practice 10: Providing a comma-separated list of languages

Where a document contains content aimed at speakers of more than one language, use Content-Language with a comma-separated list of language tags.

Best Practice 11: Using BCP 47

Follow the guidelines in the IETF's BCP 47 for language attribute values.

Best Practice 12: Deciding on language tag length

Use the shortest possible language tag values.

Best Practice 13: Using Hans and Hant codes

Where possible, use the codes zh-Hans and zh-Hant to refer to Simplified and Traditional Chinese, respectively.

Best Practice 14: Identifying the language of a target document

When pointing to a resource in another language, consider the pros and cons of indicating the language of the target document.

Best Practice 15: Using hreflang with CSS

If you want to indicate that the target document of an a element is in another language, consider the pros and cons of using hreflang with CSS.

Best Practice 16: Using flags to indicate languages

Do not use flag icons to indicate languages.

ISO-9241-151

La comenté en el artículo Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística.

El apartado 10.1 Designing for cultural diversity and multilingual de la ISO-9241-151 recoge 4 pautas:

10.1.1 General

Si se espera que los usuarios de una aplicación web sean culturalmente diversos y/o el uso de diferentes idiomas nativos, la interfaz de usuario de la web debe estar diseñada para tener las características relevantes de los diferentes grupos de usuarios. El apoyo a la diversidad cultural o lingüística se puede lograr proporcionando versiones localizadas de la interfaz de usuario.

10.1.2 Showing relevant location information

Si es relevante para la tarea se debe proporcionar información sobre el contexto geográfico. Por ejemplo, si incluyes un teléfono de contacto, indicas el país o el prefijo de país, si incluyes un horario de atención al usuario queda claro en base a qué uso horario.

10.1.3 Identifying supported languages

Si es una web multilingüe el enlace a los diferentes idiomas debe estar claro y no usar banderas, que siempre identifican países y nunca idiomas. El nombre del idioma debe ser el comúnmente aceptado para él (ISO 639) y en su correspondiente idioma.

También se recomienda, siempre que sea posible, que el cambio de idioma sea sobre la página que se está visualizando (que no se envíe a la home en otro idioma)

Aquí hago yo un inciso. Desde un punto de vista lingüístico, los términos "castellano" y "español" son equivalentes, y da igual utilizar uno u otro término pues ambos son válidos. Sin embargo, a la hora de utilizarlo como enlace al idioma de una web, es mejor usar "español" por las razones que expone el Diccionario Panhispánico de Dudas:

Para designar la lengua común de España y de muchas naciones de América, y que también se habla como propia en otras partes del mundo, son válidos los términos castellano y español. La polémica sobre cuál de estas denominaciones resulta más apropiada está hoy superada.

El término español resulta más recomendable por carecer de ambigüedad, ya que se refiere de modo unívoco a la lengua que hablan hoy más de cuatrocientos millones de personas. Asimismo, es la denominación que se utiliza internacionalmente (Spanish, espagnol, Spanisch, spagnolo, etc.). Aun siendo también sinónimo de español, resulta preferible reservar el término castellano para referirse al dialecto románico nacido en el Reino de Castilla durante la Edad Media, o al dialecto del español que se habla actualmente en esta región. En España, se usa asimismo el nombre castellano cuando se alude a la lengua común del Estado en relación con las otras lenguas cooficiales en sus respectivos territorios autónomos, como el catalán, el gallego o el vasco.

10.1.4 Using appropriate formats, units of measurement or currency

En las interfaces de usuario de uso internacional, la moneda, las unidades de medida, temperaturas, números de teléfono o código postal tienen que estar diseñados de modo que sean comprensibles y usables por una audiencia internacional.

Por ejemplo:

  • indicar siempre la moneda que corresponda, no dar por supuesto que son euros; o adaptarla según el sitio, o proporcionar el precio en diferentes monedas;
  • que los campos de formulario para solicitar la dirección den cabida a cualquier tipo de dirección de cualquier país
  • que las fechas tengan un formato inequívoco para la audiencia internacional, por ejemplo AAAA-MM-DD (ISO 8601). Aunque como hemos dicho antes esto no es muy amigable para el usuario. Además en España habrá usuarios que dudarán si lo que sigue al año es el mes o el día. Así que mejor seguir en este caso la recomendación del W3C: o bien se adapta el formato de la fecha dinámicamente según las preferencias del navegador del usuario (con las consideraciones que comentábamos) o bien se pone en formato texto.

10.1.5 Designing presentation of text in different languages

Para interfaces de usuario multilingües se deben tener en cuenta las características de las diferentes lenguas a la hora de diseñar la presentación y el layout para el texto.

No sólo la diferente longitud de un mismo texto en diferentes idiomas, sino también aspectos como que con los caracteres asiáticos (como el chino) no se visualizan bien con estilos negrita o itálica.

Relación con la accesibilidad

Es importante hacer hincapié siempre en cómo hacer un sitio accesible elimina no sólo barreras de acceso para las personas con discapacidad, sino que también favorece la usabilidad, el acceso desde dispositivos móviles (Accesibilidad y usabilidad móvil: web móvil y app nativa ) o el posicionamiento del sitio (SEO y Accesibilidad. Accesible también para buscadores), pues a menudo son argumentos de apoyo para convencer a los clientes de que deben hacer sitios accesibles.

En este caso, cumplir con las pautas de accesibilidad favorece la internacionalización del sitio.

Algunas de las buenas prácticas que se indican en los documentos que he recomendado coinciden con puntos de verificación de las WCAG 1.0 o criterios de éxito de las WCAG 2.0:

  • identificar el idioma del documento (punto de verificación 4.3/criterio de conformidad 3.1.1)
  • indicar los cambios de idioma en el documento (punto de verificación 4.1/criterio de conformidad 3.1.2)
  • especificar las abreviaciones (punto de verificación 4.2/criterio de conformidad 3.1.4)
  • identificar las palabras inusuales (criterio de conformidad 3.1.3)
  • proporcionar un mecanismo para identificar la pronunciación de palabras cuyo significado resulta ambiguo si no se conoce su pronunciación (criterio de conformidad 3.1.6)
  • separar la estructura y la información de la presentación (punto de verificación 3.3/criterio de conformidad 1.3.1)
  • marcar diferentes direcciones de lectura (criterio de conformidad 1.3.2)
  • etc.

Otros enlaces de interés

Es muy recomendable el documento Accessibility and Internationalization (PDF) de Les Kitchen (2009) En él propone ciertas actividades que apoyan la internalización de un sitio y que no hemos nombrado antes:

  • Anticipate future user groups in advance.
  • Recruit local expertise.
  • Prototype and test with target markets.
  • Use a specialized style guide.
  • Accumulate information acquired about cultures in organization-wide repositories.
  • Analyse trade-offs between effort and quality of localization.

Artículos anteriores:

jueves, 17 de mayo de 2012

Entrevista en el Heraldo de Aragón

Si os interesa conocer un poco más de mí, hoy Chema Rodriguez me entrevista en la contraportada del Heraldo de Aragón.

Modificación de la Ley 34/2002 que obliga al consentimiento expreso del usuario para el uso de cookies

Para comprender estas modificaciones y sus implicaciones, os recomiendo tres artículos:

domingo, 13 de mayo de 2012

Accesibilidad y usabilidad móvil: web móvil y app nativa

Índice

Iniciativa Web Móvil (MWI) del W3C

En Mayo de 2005 el W3C lanzó la Iniciativa Web Móvil (MWI) con el objetivo de ayudar a los desarrolladores a mejorar la accesibilidad y usabilidad de los contenidos para dispositivos móviles y resolver los problemas de interoperabilidad.

Iniciativa Web Móvil

Los principales grupos de trabajo involucrados han sido:

  • Mobile Web Best Practices Working Group, cuyo objetivo fue elaborar un conjunto de buenas prácticas que mejoraran la experiencia de los usuarios al acceder al contenido Web desde dispositivos móviles. Trabajó desde mayo de 2005 hasta diciembre de 2010, dejando publicadas dos recomendaciones:

    Ambos documentos se tratan en profundidad en los siguientes apartados de este artículo.

  • Device Description Working Group, creado para guiar el desarrollo de un repositorio de descripción de dispositivos (DDR) que pudiera ser utilizado para adaptar los contenidos a un dispositivo en particular. Trabajó desde mayo de 2005 hasta diciembre de 2008, dejando publicados diversos documentos entre los que destacan:

    • Device Description Repository Simple API, que describe la API para el acceso al DDR con el fin de facilitar y promover el desarrollo de contenido Web que se adapte al dispositivo desde el que se accede.
    • Device Description Repository Core Vocabulary, define el vocabulario, identificando las propiedades que se consideran esenciales para la adaptación de los contenidos a la web móvil (las dimensiones de la pantalla, los mecanismos de entrada, los colores admitidos, las limitaciones conocidas, etc.)

     Esquema DDR Simple API: Service, Evidence, PropertyRef, PropertyName, PropertyValue

  • Mobile Web for Social Development Interest Group, es un grupo de interés que explora cómo utilizar el potencial de las Tecnologías de la Información y la Comunicación (TIC) en los teléfonos móviles como una solución para salvar la brecha digital y proporcionar los servicios mínimos (salud, educación, gobierno, negocios, etc.) a las comunidades rurales y a la población de los países en desarrollo. Su documento más relevante es de diciembre de 2009 Mobile Web for Social Development Roadmap.

Mobile Web Best Practices 1.0 (MWBP)

El objetivo de las Mobile Web Best Practices 1.0 (recomendación desde julio de 2008) es servir de pautas para mejorar la experiencia de usuario en la navegación web a través de dispositivos móviles.

El W3C mobileOK Basic Test es el esquema para evaluar la conformidad de un sitio web de acuerdo con las Mobile Web Best Practices. Es utilizado por el validador automático online del W3C W3C mobileOK Checker. Como en todo validador automático, sólo se evalúan aquellos puntos que pueden verificarse de forma automática, los demás deberán ser verificados de forma manual.

La nota de agosto de 2009 W3C mobileOK Scheme 1.0 señala que los proveedores pueden identificar sus páginas como mobileOK, es decir, que pasan el validador automático y por tanto las pruebas básicas en él implementadas. En ese caso pueden añadir el icono:

Las Mobile Web Best Practices 1.0 (MWBP) están resumidas en una tarjeta traducida al español. Son 60 pautas organizadas en 10 principios clave que si se cumplen permiten incrementar el público que puede acceder a los contenidos, crear sitios Web y aplicaciones eficaces y hacer la navegación en la Web accesible desde más dispositivos.

Estos 10 principios generales son:

  1. Diseña para una Web única.
    Si diseñas el contenido teniendo en cuenta los diferentes dispositivos, reducirás costes, tu página será más flexible y satisfarás las necesidades de más personas.
  2. Confía en los estándares Web.
    En un mercado tan fragmentado como el de dispositivos y navegadores, los estándares son la mejor garantía de Interoperabilidad.
  3. Evita los riesgos conocidos.
    Un diseño bien planificación ayuda a reducir los problemas de usabilidad causados por pantallas y teclados pequeños, u otras funciones de los dispositivos móviles.
  4. Sé prudente con las limitaciones de los dispositivos.
    Cuando elijas una tecnología Web concreta, ten en cuenta que los dispositivos móviles tienen funciones muy diversas.
  5. Optimiza la navegación.
    La simplificación de la navegación y del uso del teclado son factores esenciales cuando se utilizan pantallas y teclados pequeños, y se tiene un ancho de banda limitado.
  6. Comprueba gráficos y colores.
    Las imágenes, los colores y el estilo destacan el contenido, pero hay dispositivos con pantallas de bajo contraste o problemas de compatibilidad con algunos formatos.
  7. Hazlo pequeño.
    Un sitio Web de tamaño reducido supondrá un ahorro de tiempo y dinero para los usuarios.
  8. Economiza el uso de la red.
    Las funciones de los protocolos Web pueden mejorar la experiencia del usuario al reducir los retrasos y los tiempos de espera en la red.
  9. Facilita la entrada de datos.
    En los dispositivos móviles, los teclados y demás métodos de introducción de datos pueden ser tediosos para el usuario. Un diseño eficaz minimiza su uso.
  10. Piensa en los usuarios de la Web móvil.
    Los usuarios de la Web móvil necesitan información sintetizada al disponer de poco tiempo y existir distracciones externas.

MWBP y las WCAG

Las MWBP 1.0 no describen cómo hacer contenido Web accesible en dispositivos móviles, para ello están las WCAG. Las MWBP 1.0 explican cómo mejorar la experiencia de usuario en el acceso al contenido web desde los dispositivos móviles.

Ambas se solapan en muchos puntos, porque los usuarios de dispositivos móviles y las personas con discapacidad se enfrentan a barreras similares al interactuar con el contenido web.

WCAG y MWBP tienen como objetivo mejorar la interacción de los usuarios de Internet que experimentan barreras, ya sea debido a la discapacidad o el dispositivo utilizado para acceder a la Web.

Sin embargo, las WCAG y MWBP tienen enfoques ligeramente diferentes. Por ejemplo, una característica clave de los criterios de éxito de las WCAG 2.0 es que están diseñados específicamente para ser declaraciones comprobables. Aunque algunas de las MWBP se pueden comprobar, no tienen el propósito de ser comprobables.

[A lo cual añado yo que las MWBP no tienen niveles de prioridad como sí los tienen las WCAG]

Mientras que los dos documentos muestran un solapamiento significativo en muchas áreas, hay diferentes grados de superposición entre los distintos requisitos técnicos, de modo que no siempre hay una correspondencia uno-a-uno entre ellos.

Por ejemplo, las WCAG tienen algunos requisitos que son específicos para las necesidades de accesibilidad de las personas con discapacidad, y que no son relevantes para dispositivos móviles (por ejemplo, los requisitos que se refieren específicamente a la tecnología de asistencia).

A la inversa, las MWBP tienen otros requisitos que son específicos para los dispositivos móviles solamente (por ejemplo, los requisitos para minimizar el consumo de la batería y potencia de la CPU).

Sin embargo, en general muchos requisitos son aplicables para ambos grupos de usuarios (por ejemplo, los requisitos para el contraste de colores, los tamaños de fuente flexibles, etc.)

Traducción de un fragmento del documento Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)

Si tu sitio ya cumple con las WCAG será sencillo cumplir con las MWBP y viceversa.

Algunas de las pautas de las MWBP que os resultarán familiares son:

  • Crea documentos gramaticalmente válidos.
  • Asigna teclas de acceso rápido a los menús y a las funciones más utilizadas.
  • Facilita un equivalente en forma de texto para cada elemento no textual.
  • No utilices medidas absolutas.
  • Etiqueta cada control de formulario y asocia la etiqueta con los controles.
  • Crea mecanismos de navegación consistentes.
  • No hagas refrescos automáticos de las páginas sin informar al usuario y permitirle pararlos.
  • No abras pop-ups y no cambies la ventana actual sin informar al usuario.
  • Usa un lenguaje simple y claro.
  • Identifica claramente el destino de cada enlace.
  • Asegúrate de que la información transmitida a través de los colores también esté disponible sin color.
  • Asegúrate de que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste.
  • Proporciona un título corto y descriptivo a las páginas.
  • etc.

Otras pautas de las MWBP más específicas para los dispositivos móviles (aunque beneficiarán a todos los usuarios) son:

  • Intenta que la URI de entrada al sitio sea tan corta como pueda.
  • Incluye sólo la navegación básica en la parte superior de la página para que el contenido de la página se vea sin escrolar.
  • Intenta reducir al máximo el número de enlaces externos.
  • Sirve sólo el contenido que el usuario ha pedido: no descargues contenido sin su permiso pues los usuarios de móviles pagan a menudo el ancho de banda, por lo que el contenido ajeno a sus necesidades, especialmente la publicidad, les cuesta tiempo y dinero y contribuye a una experiencia insatisfactoria.
  • Asegúrate de que el tamaño global de la página es adecuada a las limitaciones de memoria del dispositivo.
  • Limita el scroll a una sola dirección a no ser que el desplazamiento secundario no pueda ser evitado.
  • Evita las imágenes grandes o de alta resolución, a no ser que sea información crítica.
  • Si las imágenes tienen una tamaño intrínseco, específica el tamaño de las imágenes en el marcado de la página y redimensiónalas en el servidor.
  • Reduce el tamaño de las CSS.
  • No confíes en que las cookies estén disponibles.
  • Proporciona información de caché en las respuestas HTTP.
  • Evita la introducción de texto libre por parte del usuario siempre que sea posible.
  • Proporciona valores por defecto preseleccionados siempre que sea posible.
  • etc.

Además desaconsejan explícitamente los frames, los mapas de imagen, los pop-ups y las tablas para maquetar. En el caso de los scripts sólo si no hay otra forma de lograr sus objetivos, pues se indica que no son soportados por todos los dispositivos, aumentan el consumo de energía y por tanto disminuyen la duración de la batería.

Para comprender la relación entre ambos estándares, sus similitudes y diferencias, hay cuatro documentos que se introducen en la nota Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG):

Además, es de gran utilidad el documento Table of Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities, donde se esquematiza en forma de tabla el paralelismo entre la experiencia de los usuarios con discapacidad y la de los usuarios de dispositivos móviles, indicando la correspondencia entre los puntos de verificación de las WCAG 1.0, los criterios de éxito de las WCAG 2.0 y las pautas de las MWBP.

Otros enlaces recomendados:

Por último recordar que actualmente no hay ninguna legislación que incluya la obligación de cumplir con las MWBP, como por el contrario sí ocurre con las WCAG.

Mobile Web Application Best Practices

Las Mobile Web Application Best Practices son recomendación desde diciembre de 2010. Amplían las MWBP, que como hemos visto ponen el foco en ofrecer una buena experiencia de navegación por Internet desde una amplia gama de dispositivos móviles.

Por su parte, las Mobile Web Application Best Practices recogen las mejores prácticas para las aplicaciones Web que se ejecutan en el navegador y/o que usan las capacidades de los dispositivos avanzados (por ejemplo la geolocalización), así como advierten de las prácticas perjudiciales para asegurar la mejor experiencia de los usuarios de dispositivos móviles.

Definen "aplicación web" en este contexto como la página web (XHTML o variante de la misma +CSS) o selección de páginas web entregadas a través de HTTP. Sin embargo, tal y como indican, en muchos casos son también aplicables a los Web Widget (ver "Introducción a los W3C Widgets", de Andrés Nieto) o iniciativas propias de cada proveedor.

Son 32 pautas más 3 consideraciones adicionales. Se advierte que no es necesario aplicar todas las pautas, si no que su aplicación o no ha de considerarse en cada caso. Algunas sólo son aplicables si el dispositivo tiene ciertas capacidades (por ejemplo, el acceso a la información del dispositivo, como la ubicación) pero presuponen que al menos tienen soporte para XHTML, CSS y JavaScript.

El W3C resume las Mobile Web Application Best Practices en una tarjeta (PDF) que agrupa las pautas en los siguientes principios:

  • Optimiza el tiempo de respuesta. Cada detalle importa en las aplicaciones Web móviles y algunos aspectos técnicos puede aumentar significativamente la experiencia del usuario.
  • Libertad del usuario. Los dispositivos móviles se utilizan en diferentes contextos, desde pasar el rato en su casa hasta las peticiones urgentes imprevistas. Permite a los usuarios conocer y controlar lo que sucede para ganar su confianza.
  • Diseña para la flexibilidad. Las aplicaciones Web se ejecutan en entornos heterogéneos y cambiantes. La flexibilidad le permite hacer frente a más dispositivos y usuarios a un costo reducido
  • Recuerda los principios Web. Los dispositivos móviles son sólo una manera de acceder a la web. Los principios genéricos de la web son también aplicables al desarrollo de aplicaciones Web móviles robustas.
  • Spare the network. Usa adecuadamente las características del protocolo Web para reducir los cuellos de botella y la latencia de la red.
  • Explota las características específicas de los dispositivos móviles. Algunas tecnologías Web son especialmente relevantes para los dispositivos móviles. Aprende a usarlas.

Algunos ejemplos de pautas son:

  • Usa las cookies con moderación.
  • Replica los datos en local.
  • Informa al usuario acerca del acceso y uso a la información personal o del dispositivo.
  • Usa el elemento meta viewport para el identificar el tamaño de pantalla deseado.
  • Haz los números de teléfono Click-to-call (<a href="tel:[PHONE-NUMBER]">[PHONE-NUMBER]</a>)
  • Conserva el foco en las páginas que se actualizan dinámicamente.
  • etc.

Enlace recomendado: WAI ARIA support on iOS, sobre el soporte de los atributos WAI ARIA en iPhone 4 e iPad 1.

 

Guías específicas de accesibilidad para el desarrollo de apps nativas en diferentes tipos de dispositivos

Muchos de los principios de usabilidad y accesibilidad de los documentos comentados anteriormente pueden aplicarse a las apps nativas. Además, tanto Android, Apple, Blackberry o Windows tienen sus propias guías.

Android

Novedad 2018: he publicado un artículo muy detallado Apps nativas de Android accesibles donde explico cómo hacer una app nativa de Android accesible, con ejemplos de código, y cómo aplicar los requisitos de la EN 301 549.

En la guía para desarrolladores de Android encontramos dos apartados de interés:

  • Accessibility.

    Muchos usuarios de Android tienen alguna discapacidad que les obliga a interactuar con dispositivos Android de diferentes maneras. Esto incluye a los usuarios que tienen discapacidades visuales, físicas o relacionadas con la edad que les impide ver o usar una pantalla táctil.

    Android proporciona características y servicios de accesibilidad para ayudar a estos usuarios a utilizar sus dispositivos más fácilmente, incluyendo text-to-speech, haptic feedback, trackball y D-pad navigation, que mejoran su experiencia. Los desarrolladores de aplicaciones para Android pueden aprovechar estos servicios para hacer sus aplicaciones más accesibles y también para crear sus propios servicios de accesibilidad.

    Ofrece dos recursos:

    • Making Applications Accessible. Development practices and API features to ensure your application is accessible to users with disabilities.
    • Se desarrollan las siguientes:

      • Cómo etiquetar todos los elementos de la interfaz de usuario.
      • Cómo hacer todos los elementos de la interfaz de usuario accesibles con un control de dirección como un trackball o D-pad (activación del foco, control del orden del foco, etc.)
      • Construcción de componentes personalizados accesibles (implementación de métodos de la API de accesibilidad, envío de eventos de accesibilidad, etc.)
      • Testear la aplicación mediante la activación de los servicios de accesibilidad, como TalkBack y Explore by Touch, o intentar utilizar la aplicación utilizando sólo los controles de dirección.
    • Building Accessibility Services. How to use API features to build services that make other applications more accessible for users.
  • Best Practices, que tiene los siguientes subapartados:

    • Compatibility
    • Supporting Multiple Screens
    • Supporting Tablets and Handsets
    • UI Guidelines
    • Designing for Performance
    • Designing for Responsiveness
    • Designing for Seamlessness Designing for Security

Apple

En la web de desarrolladores de Apple tenemos la serie de documentos Accessibility Programming Guide for iOS que se centra en cómo hacer las aplicaciones accesible mediante VoiceOver. Para ello cuenta con tres documentos:

  • Accessibility on iPhone: se describe brevemente cómo funciona VoiceOver en el dispositivo e introduce la interfaz de programación y las herramientas que se pueden utilizar para hacer que una aplicación sea accesible.
  • Making Your iPhone Application Accessible: proporciona una guía detallada para hacer que una aplicación sea accesible a los usuarios de VoiceOver.
  • Testing the Accessibility of Your iPhone Application: que puede realizarse mediante el Accessibility Inspector del simulador o directamente con VoiceOver en el dispositivo. Explican como testear la aplicación con VoiceOver.

Enlace recomendado: Accessibility for iPhone and iPad apps, Matt Gemmell

Blackberry

En la Accessibility Development Guide 6.0 de Blackberry podemos encontrar cuatro documentos:

  • "Understanding accessibility"
  • "Best practice: Designing accessible applications", en la que se ofrecen 17 pautas organizadas en cuatro temas:

    • Guidelines for UI design
    • Guidelines for navigation
    • Guidelines for text
    • Guidelines for color and images
  • "Developing accessible BlackBerry device applications by using the Accessibility API"
  • "Related resources", con un enlace destacado para la descarga de BlackBerry Screen Reader.

Windows

En el MSDN de Microsoft encontramos para Windows Phone un apartado User Experience Design Guidelines for Windows Phone, pero no hay ningún apartado específico sobre accesibilidad (por lo visto no es muy accesible)

Sin embargo para Windows Mobile 6.5 sí tenemos una guía que contiene dos secciones:

También en el apartado Design Guidelines hay un apartado "Accessibility and Ergonomic Guidelines"


Enlace recomendado: Are your mobile apps accessible? , RNIB

 

¿Cómo usan las personas con discapacidad un dispositivo móvil?

Sin embargo, todo lo dicho anteriormente no tiene mucho sentido sin conocer cómo usan los dispositivos móviles las personas con discapacidad.

En este caso lo más práctico no es contarlo, sino verlo, para ello podéis consultar mi lista de reproducción de Youtube "Accesibilidad móvil"

Novedad 2018: he publicado un artículo muy detallado Apps nativas de Android accesibles donde incluyo información y recursos sobre cómo usan las personas con discapacidad los dispositivos móviles y los problemas que suelen encontrarse.

Otras referencias sobre UX en dispositivos móviles

 

Conclusiones

Para que los contenidos web sean accesibles, independientemente del dispositivo con el que vayan a ser accedidos, deben cumplir con las WCAG.

De forma complementaria, para mejorar la experiencia de usuario en la navegación web desde dispositivos móviles, debemos aplicar las Mobile Web Best Practices (MWBP). Como hemos visto, el W3C dispone de un validador automático W3C mobileOK Checker que permite verificar aquellas pautas que admiten validación automática.

Cuando tenemos una aplicación RIA, para asegurar una mejor experiencia de usuario debemos aplicar también las Mobile Web Application Best Practices, que son una ampliación de las WMBP, pero orientadas a las aplicaciones RIA y el uso de las capacidades de los dispositivos avanzados.

En el caso de las aplicaciones nativas es necesario conocer estos documentos y aplicar aquellas pautas que sean aplicables. Pero es necesario conocer también las guías específicas de accesibilidad de Android, Blackberry, Apple o Windows.

Pero sobre todo, para comprender el sentido de todo esto, es necesario conocer las barreras que habitualmente encuentran los usuarios al acceder al contenido web desde un dispositivo móvil, así como conocer las barreras que encuentran las personas con discapacidad y cómo estas utilizan los dispositivos móviles.

Artículos relacionados:

domingo, 6 de mayo de 2012

Falsos positivos de validadores automáticos de accesibilidad basados en las WCAG 2.0

Última actualización: 21/07/2020

En este artículo recopilo falsos errores que reportan los validadores automáticos de accesibilidad.

Los falsos positivos y falsos negativos del validador automático de accesibilidad del Observatorio de accesibilidad web los recojo en el artículo: Validador del Observatorio de Accesibilidad Web - Rastreador OAW. Validaciones y fiabilidad (Parte II)

Falso Error 1: campo de texto sin LABEL asociado... pero que tiene un TITLE adecuado

Los criterios de conformidad 1.1.1, 1.3.1, 3.3.2 y 4.1.2 hacen referencia a que un campo de formulario debe estar correctamente identificado, lo que en las WCAG 1.0 era el punto de verificación 12.4 Asocie explícitamente las etiquetas con sus controles. [Prioridad 2]

En estos cuatro criterios de conformidad de las WCAG 2.0 se admite una de estas dos técnicas suficientes para cumplirlos:

  • H44: Using label elements to associate text labels with form controls
  • H65: Using the title attribute to identify form controls when the label element cannot be used

Aunque lo más recomendable siempre es utilizar la técnica H44 y asociar cada campo de formulario (salvo los de tipo button o los input de tipo image, submit, reset y hidden) con su correspondiente label, hay casos en los que no podemos usar label o este podría resultar confuso. En esos casos podemos usar la técnica H65, es decir, no etiquetar el campo con label sino usar el atributo title para etiquetar el campo e identificar su propósito.

Ejemplos en los que podríamos usar el atributo title de un campo de formulario para etiquetarlo en vez de etiquetarlo con label:

  • Cuando para introducir una fecha o un código de cuenta en un formulario tenemos varios campos (por ejemplo campos diferentes para día, mes, año). En estos casos podemos identificar cada uno de esos campos con el atributo title (sin necesidad de que cada uno tenga un label)
  • Cuando tenemos un campo de búsqueda y un botón Buscar sin una etiqueta previa "Buscar" o "Buscador". Si debemos respetar el diseño podemos etiquetar el campo de búsqueda mediante su atributo title. En este caso además contamos con la técnica suficiente G167 Using an adjacent button to label the purpose of a field, en la que se indica concretamente que un botón "Buscar" justo a continuación de un campo de búsqueda es suficiente para cumplir con el criterio de conformidad 3.3.2
  • Una tabla en la que el contenido de alguna de sus celdas sea un campo de formulario. Por ejemplo la tabla resumen de tu pedido en un ecommerce, en la que el contenido de una de sus columnas sea un campo editable con el número de unidades de cada producto.

Sin embargo, hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un campo sin un label asociado, aunque este tenga un atributo title adecuado.

Validadores que SÍ dan este falso error: Examinator, tenon.io

Validadores que NO dan este falso error: TAW, AChecker, Deque Worldspace Free Analysis, AccessMonitor

Falso Error 2: imagen que es un enlace y tiene ALT vacío... pero que va acompañada por un texto dentro del enlace

Es el siguiente caso, correcto como se puede consultar por ejemplo en la técnica H2, y que por tanto no está incumpliendo el criterio de conformidad 1.1.1:

<a href="ayuda.html"><img src="image/ayuda.gif" alt="" /> Ayuda</a>

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran una imagen dentro de un enlace si dicha imagen tiene ALT vacío, sin tener en cuenta que puede ser un caso como el descrito.

Validadores que SÍ dan este falso error: AChecker

Validadores que NO dan este falso error (o solo advierten que las imágenes decorativas es mejor incluirlas en las CSS): TAW, Examinator , Deque Worldspace Free Analysis, AccessMonitor

Falso Error 3: H2 presente en el código antes que un H1... sin tener en cuenta que estén bien marcados

La técnica H42 Using h1-h6 to identify headings, incluye un ejemplo en el cual el título del contenido principal coincide con el título de la página y está marcado como "H1" aunque no es el primero que aparece en la página. El contenido de la primera y tercera columna es menos importante y está marcado con "H2".

No es necesario que H1 aparezca antes que H2, lo importante es que realmente el título marcado como H1 sea de primer nivel y los marcados como H2 de segundo nivel.

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un encabezado superior colocado en el código después de uno inferior, cuando solo deberían reportar una advertencia para que se revise que están bien marcados.

Validadores que SÍ dan este falso error: Deque Worldspace Free Analysis, Total11y

Validadores que NO dan este falso error: TAW (en una versión anterior sí daba error pero ya está corregido), Examinator, AChecker, AccessMonitor

Falso Error 4: indicar en cualquier caso que es obligatorio incluir enlaces para saltar bloques de contenido y un primer enlace en la página que lleve al contenido principal de la misma

El criterio de conformidad 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web (Nivel A), se puede cumplir de dos formas diferentes (tal y como se puede consultar en Understanding SC 2.4.1):

  • Agrupando los bloques de contenido de manera que los productos de apoyo puedan reconocerlos y saltarlos: estructurar las páginas con encabezados, agrupando los enlaces en listas, etc.
  • Proporcionando enlaces para saltar los bloques de contenido, en cuyo caso se ofrece un listado de técnicas de las que es necesario elegir al menos una, entre ellas las dos que comento.

Por tanto, no se puede reportar siempre y en todos los casos como error que no haya un enlace al comienzo de la página para ir al contenido principal. Puede que la página esté bien estructurada y por tanto se esté cumpliendo con el criterio de conformidad 2.4.1. Puede además que no haya claramente un área de contenido principal y por tanto este enlace no resulte útil.

De la misma manera, no se puede reportar siempre y en todos lo casos que no haya enlaces para saltar bloques de contenido.

Y en cualquier caso, no se debería incluir como error ambas, sino indicar que al menos es necesario una de ellas.

Validadores que SÍ dan este falso error: Examinator, AccessMonitor

Validadores que NO dan este falso error: TAW, Deque Worldspace Free Analysis, AChecker

Falso Error 5: longitud de la descripción del ALT demasiado larga ... pero tiene menos de 150 caracteres

Las WCAG 2.0 no especifican la longitud máxima del atributo ALT. El documento Techniques For Accessibility Evaluation And Repair Tools del W3C indica que la longitud máxima del atributo ALT será de 150 caracteres, aunque otros recursos indican no sobrepasar los 100 caracteres.

Lo apropiado entonces sería que ante un texto alternativo entre 100-150 caracteres el validador ofreciera en todo caso una advertencia, pero no un error.

Validadores que reportan un error:

  • Examinator califica como "Muy mal" un texto alternativo entre 100-150 caracteres.

    Error de eXaminator que indica que el atributo ALT es demasiado largo porque sobrepasa los 100 caracteres

  • tenon.io

Validadores que lo reportan como una alerta

Otros validadores solo te dan una alerta si es mayor de 100 caracteres para que revises la longitud.

  • AChecker, da como "error probable" un ALT mayor de 100 caracteres.
  • Wave, da una alerta si el ALT es mayor de 100 caracteres.

Validadores que no dan error cuando el texto alternativo tiene una longitud entre 100-150 caracteres:

Falso Error 6: reportan como error el uso de accesskey

Las WCAG 2.0 no prohiben el uso de teclas de acceso rápido. Lo que sí debe hacerse es usarlas bien, por ejemplo no asignar una misma tecla a dos enlaces diferentes, o no usar teclas que colisionen con los atajos de menú de los navegadores, como expliqué en Qué teclas de acceso rápido (accesskey) utilizar.

Estés o no a favor de las accesskey, una validador que evalúa de acuerdo a las WCAG 2.0 no puede reportar como error su uso.

Validadores que lo reportan como un error: tenon.io

Hasta aquí los que he detectado por ahora. ¿Conocéis más falsos errores? Es importante documentarlos, porque es difícil convencer a un cliente de que el validador se equivoca, por mucho que lo argumentes.

Artículos relacionados: