Creo que uno de los aspectos más importantes para la accesibilidad de los contenidos en el web así como para la indexación y clasificación de los contenidos en general es la identificación del idioma. Me refiero a algo tan simple como el declarar en qué idioma se encuentran los contenidos de una página. Sin embargo esto es algo que ocurre con muy poca frecuencia.

Cualquiera que haya utilizado alguna aplicación asistiva como Jaws para evaluar accesibilidad o incluso como herramienta de navegación sabe que no es fácil entender un documento en castellano leído con un sintetizador configurado para leer en inglés o a la inversa. Del mismo modo, los indexadores como Googlebot deben realizar esfuerzos especiales mediante algoritmos complejos para identificar el idioma principal de un documento para luego analizar sus contenidos. Es evidente que para poder analizar, indexar y clasificar los contenidos de una página primero debemos conocer el idioma.

Imagino que el origen de este descuido tiene raíces en el idioma original de las tecnología web: el inglés. Desde la perspectiva de los usuarios (y desarrolladores) angloparlantes, el resto del mundo habla un idioma extranjero, por lo tanto ellos normalmente no sienten la necesidad de preocuparse de identificar el idioma dominante del web en cada uno de sus documentos. Evidentemente esto es un error. Y es más incorrecto aún cuando nosotros, desarrolladores hispanoparlantes (y en general los hablantes de cualquier otro idioma), omitimos esta declaración. El hecho es que el idioma por defecto del web es el inglés (aunque esto no es técnicamente correcto, como veremos más adelante) y nosotros estamos obligados a identificarnos para asegurarnos de que nuestros contenidos sean correctamente comprendidos. No lo puedo asegurar por el hermetismo de Google respecto a sus algoritmos, pero imagino que será más cortés y benevolente con nosotros si le ahorramos un considerable tiempo de procesamiento y análisis lingüístico declarando explícitamente el idioma en que se encuentra nuestro contenido. Para salir de las dudas, esta misma pregunta la he enviado a un grupo de discusión sobre buscadores y al mismo Google. Nada se pierde con intentar, no?

De todos modos, los beneficios de marcar correctamente el idioma van más allá de los buscadores. Cualquier proceso automático sobre el contenido podría utilizar este antecedente, además de los ya mencionados beneficios para la accesibilidad.

Entonces, ¿cómo deberíamos identificar el idioma? En HTML 4.01 se especifica lo siguiente:

This attribute specifies the base language of an element’s attribute values and text content. The default value of this attribute is unknown.

[…] The lang attribute’s value is a language code that identifies a natural language spoken, written, or otherwise used for the communication of information among people. Computer languages are explicitly excluded from language codes.

En la práctica, esto nos indica que: el atributo lang indica el lenguaje del elemento donde se declara y de sus atributos; el valor por defecto es desconocido; es un código que identifica un lenguaje natural. Veamos esto en detalle.

Alcance del Atributo lang

El atributo lang determina el idioma del elemento al que pertenece, pero también el idioma de sus demás atributos. Por ejemplo, en el siguiente ejemplo tanto el contenido del atributo title, así como el propio contenido World Wide Web Consortium están definidos como texto en inglés. Recordemos que en HTML el orden de los atributos no tiene ningún significado o valor especial.

<a href=”http://www.w3c.org/” title=”W3C web site” lang=”en”>World Wide Web Consortium</a>

Valor por Defecto

Cuando este atributo no se indica, se debe asumir que se desconoce el idioma, a menos que el elemento sea hijo de otro elemento en un nivel superior que sí declare idioma. En el siguiente ejemplo, el texto en p está definido como español, pero dentro de él está el texto World Wide Web Consortium en el elemento em que está identificado como inglés.

<p lang=”es”>El <em lang=”en”>World Wide Web Consortium</em> es un consorcio internacional que define estándares para el web.</p>

Códigos de Idioma

Los códigos de idioma están definidos en RFC 1766 y en ISO 639. La siguiente tabla presenta algunos códigos:

XHTML

En XHTML el procedimiento es muy similar:

Use both the lang and xml:lang attributes when specifying the language of an element. The value of the xml:lang attribute takes precedence.

La diferencia es que además de lang se debe usar el atributo xml:lang. Si ambos están decarados, se utilizará el valor de éste último.

Criterios de Uso

Cuándo es necesario definir el idioma:

• Al principio de cada documento HTML como atributo del elemento head: <HTML xmlns="http://www.w3.org/1999/xhtml” lang="es">. Esta declaración rige para todo el documento y no es necesario volver a identificar el idioma a menos que ocurra un cabio dentro del contenido.
• Cuando ocurre un cambio de idioma dentro del contenido. Por ejemplo, si el documento está declarado como español en head, pero dentro del texto hay una frase en inglés, se debería identificar usando cualquier elemento que sea apropiado, por ejemplo <em lang="en">

No está de más recordar que podemos utilizar lang en prácticamente cualquier elemento de HTML.

Conclusión

Hemos visto que técnicamente es simple marcar el contenido con el idioma correcto. Incluso es posible implementar interfaces gráficas para editores de contenido WYSIWYG de modo de no intervenir el código. Los beneficios pueden no ser evidentes, pero ocurren: se mejora la acesibilidad, el contenido queda enriquecido estructuralmente al identificarse apropiadamente fragmentos de diversos contenidos.

Mayor información sobre internacionalización e idiomas en el artículo Language tags in HTML and XML del W3C.

El año pasado estuve realizando algunas consultorías sobre accesibilidad que resultaron muy interesantes. Sobre todo no deja de asombrarme el entusiasmo de los miembros de los equipos involucrados. Eso es algo bueno en sí mismo. Sin embargo no es de eso de lo que quiero hablar en este momento, sino de una herramienta que utilicé por primera vez en este contexto.

Muchos estamos familiarizados con las personas como herramienta para lograr una mayor aproximación de los equipos hacia los usuario finales. Se trata básicamente de lo siguiente: identificar perfiles claros de grupos de usuarios, determinar las caracterísiticas más comunes de cada uno de esos perfiles y finalmente crear una narración breve con la descripción de un personaje inventado que reúna estas características. Se trata de inventar personajes con esas características, incluso les asignamos un nombre y una fotografía para hacerlos más reales, de modo que el equipo pueda tener un rostro con características propias para quien desarrollar el sitio, aplicación o funcionalidades específicas.

Las personas, como herramienta de diseño centrado en el usuario, son tremendamente útiles, en tanto permiten a los miembros de un equipo tener una aproximación más real con el destinatario final del proyecto. Normalmente habrá tantas personas como perfiles de usuarios se identifiquen para cada proyecto.

Lo interesante es que podemos utilizar las personas como herramienta de accesibilidad, para facilitar la implementación de técnicas que mejoren la accesibilidad de un proyecto.

En un proyecto ideal, deberíamo considerar la accesibilidad como un parte integral desde el principio del desarrollo y esto implica que no se debería realiar un esfuerzo adicional para mejorar la accesibilidad de un sitio, por ejemplo. En esta situación, podría existir una o dos personas que permitan identificar características generales de usuarios con las discapacidades más comunes en el web, una persona con ceguera total y otra con problemas de visión no extremos. Un ejemplo puede ser el siguiente: tenemos una persona que, a grandes rasgos, se llama Diego, tiene 55 años, tiene poblemas de miopía avanzados, usa internet explorer para navegar pero aumenta el tamaño de los textos al máximo que le permite el navegador para facilitar la lectura. Durante el desarrollo del proyecto podríamos presenciar esta conversación:

Jefe de Proyecto:

Tenemos que desarrollar la página de registro, para aumentar la seguridad y los riesgos del registro mediante scripts automatizados se propone el uso de capchas.

Miembro del equipo o reponsable de accesibilidad:

Me parece, pero debemos verificar como interactuaría Diego con los capchas. Tú sabes, son imágenes y normalmente no podrá aumentar su tamaño. Creo que deberíamos estudiar un mecanismo altenativo o ver la forma de facilitar eu amplíe la imagen. Por otro lado debemo asegurarnos de que exista también un méodo alternativo para Ana que es ciega y no podrá registrarse si no puede conocer el contenid de los capchas.

La posibilidad de personalizar características simplifica mucho el proceso de revisar los requerimientos de grupos de usuarios con características particulares.

Volviendo a la experiencia que mencioné al principio, como mi rol se trataba de asesorar en la adaptación de un sitio ya existente a normativas de accesibilidad, creé un grupo de personas que reunieran las características más notorias de los potenciales usuarios discapacitados de este sitio. El resultado es tremendamente positivo, los miembro de los equipos pueden personificar características que de otro modo serían abstractas y difícilmente asimilables. Eso garantizará un mayor éxito en la implementación de accesibilidad y una mayor consciencia en el equipo.