Artículo anterior:
Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística

El punto de verificación 9.5 de las WCAG 1.0 de nivel AAA indica Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario. [Prioridad 3] Por ejemplo, en HTML, especifique los atajos a través del atributo "accesskey"

En las WCAG 2.0 deja de ser un criterio de conformidad y pasa a ser una técnica adicional del criterio 2.4.1 de nivel A Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web".

Aunque no es obligatorio, yo sí que recomiendo incluir atajos de teclado. La duda que surge entonces es ¿qué accesskey incluir de forma que no entren en conflicto con las teclas de atajo de los menús del navegador? ¿hay algún estándar?

UK Government accesskeys standard

El Gobierno del Reino Unido estableció en 2002 las siguientes teclas de acceso rápido para sus portales web:

• S - Skip navigation
• 1 - Home page
• 2 - What’s new
• 3 - Site map
• 4 - Search
• 5 - Frequently Asked Questions (FAQ)
• 6 - Help
• 7 - Complaints procedure
• 8 - Terms and conditions
• 9 - Feedback form
• 0 - Access key details

Consultar en: Uk Guidelines for government websites (PDF) (capítulo 2 "Content of websites". Apartado 2.4 "Building in universal accessibility + checklist". Subapartado 2.4.4 "UK Government accesskeys standard".

Estas accesskey se siguen utilizando como se observa por ejemplo en la web Directgov (UK government's digital service for people in England and Wales)

Swedish Government accesskeys standard

En Suecia, en las Swedish National Guidelines for Public Sector Websites (2008) (PDF), que establecen las normas a seguir por los portales de la Administración Pública, se definen también las teclas de acceso rápido que se han de utilizar.

Según se indica, están basadas en las del Reino Unido (The choices of access keys are inspired by the UK Government access keys):

• S - Skip navigation, go directly to text content
• 0 - “About the website”, accessibility information. Provided details on access keys
• 1 - “Home” page
• 2 - News. Collection of news
• 3 - Content outline. A site map, or perhaps A-Z
• 4 - Search. Should be connected to the search field that searches the entire website
• 5 - Frequently Asked Questions (FAQ)
• 6 - Help. For example, about a specific service.
• 7 - Contact us. Page with contact details to important functions within the government agency.
• 8 - Legal information. Page that describe the website’s privacy policy and how legal information such as cookies are handled.

Según se especifica, en la página "About the website" se deben indicar las teclas utilizadas y explicar su uso en diferentes navegadores y sistemas operativos.

Ninguna de estas teclas colisiona con los atajos de menú de los navegadores. La "S" no genera conflicto en los navegadores en castellano, aunque indican que en la versión sueca de IE6 sí colisiona con un menú.

• Accesskey standards
• Atajos de teclado en documentos Web
• Access key systems

• Asociación compleja de radios y labels de forma accesible
• Consejos avanzados de accesibilidad web
• Respuesta a 25 dudas habituales sobre accesibilidad web
• HTML 5 y accesibilidad

Artículo anterior:Qué teclas de acceso rápido (accesskey) utilizar

Última actualización: 26/03/2012

En el artículo Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística definí qué es un estándar y la diferencia entre estándares oficiales (o “de jure” o formales) y estándares “de facto” (o no formales)

En dicho artículo traté los estándares oficiales, repasando las diferentes normas ISO existentes, donde destaca la norma ISO 9241-151 que presenta una checklist de validación.

Asimismo repasé diferentes propuestas basadas en estas normas ISO que incluían formas prácticas de aplicarlas en una evaluación heurística, en especial WUEP (Web Usability Evaluation Process)

Por ello incluí la descarga de una excel con las subcaracterísticas (y descripción), atributos (y su descripción) y métricas, a modo de herramienta de ayuda, para la elaboración de una evaluación de usabilidad de una web de acuerdo a la ISO 25000 (SQUARE), según el modelo propuesto por WUEP (Web Usability Evaluation Process)

Índice

• HHS Guidelines
• 247 directrices de usabilidad de Userfocus
• Nielsen Norman Group Guidelines
• Swedish National Guidelines for Public Sector Websites
• SIRIUS
• Australia Government Usability Checklist
• Guía para el Desarrollo de Sitios Web del Gobierno de Chile
• Usability Guidelines del MIT
• Directrices de usabilidad para sitios web del Estado colombiano
• Otros enlaces de interés

HHS Guidelines

Las "HHS Guidelines" son las directrices de diseño web y usabilidad del Gobierno de EEEUU. Fueron desarrolladas por el U.S. Department of Health and Human Services (HHS) en 2004, de ahí que se las conozca como las HHS Guidelines.

Están disponibles en formato PDF en el documento Research-Based Web Design and Usability Guidelines (PDF 20.64 MB)

Fueron realizadas y revisadas por diseñadores y expertos de usabilidad basándose en la investigación de diferentes campos (citan en concreto: cognitive psychology, computer science, human factors, technical communication y usability)

En la actualidad cuenta con 209 directrices (en la primera edición eran 187) que, tras un estudio de cardsorting, se agruparon en 18 temas:

1. Proceso de diseño y evaluación (11 directrices)
2. Optimizando la experiencia de usuario (16 directrices)
3. Accesibilidad (13 directrices)
4. Hardware y software (5 directrices)
5. La página de inicio (9 directrices)
6. Esquema de la página (layout) (13 directrices)
7. Navegación (12 directrices)
8. Desplazamiento (scrolling) y paginado (5 directrices)
9. Encabezados, títulos y etiquetas (8 directrices)
10. Enlaces (14 directrices)
11. Apariencia del texto (11 directrices)
12. Listas (9 directrices)
13. Controles y Widgets (25 directrices)
14. Gráficos, imágenes y multimedia (16 directrices)
15. Escribiendo contenido web (11 directrices)
16. Organización del contenido (9 directrices)
17. Búsqueda (9 directrices)
18. Test de usabilidad (13 directrices)

Se puede consultar de forma individual cada uno de estos capítulos en la página Guidelines de la web usability.gov Esta web del Gobierno de EEUU recoge la metodología que se debe aplicar en la construcción de un sitio web bajo una metodología de Diseño Centrado en el Usuario, dentro de la cuál cumplir con estas directrices sólo es un paso más. Traté en profundidad esta web y su metodología propuesta en el artículo La usabilidad como metodología para el desarrollo de una aplicación

Dentro de cada capítulo las directrices están ordenadas de más a menos importantes. La estructura de cada directriz es la siguiente:

Como se aprecia consta de:

• Numeración y título de la directriz ("1:1 Provide Useful Content")
• Guideline, título extendido de la directriz;
• Comments, descripción de la directriz indicando en qué consiste y por qué hay que cumplirla;
• Sources, referencias sobre esta directriz;
• Ejemplos, solo disponibles en algunas directrices.
• Relativa Importance, importancia de la directriz que están clasificadas de 1 a 5 (5 las más importantes, 1 las menos importantes) La clasificación fue llevada a cabo por una encuesta a numerosos expertos en usabilidad.
• Strength of Evidence, indica la "medida de confianza" clasificada de 1 a 5 (5 las que mayor nivel de confianza ofrecen y 1 las que menos) La medida de confianza está basada en la calificación dada por numerosos expertos en usabilidad (y en la que, según se indica, hubo alto grado de coincidencia) que buscaron evidencias de esa directriz en investigaciones, estudios, resultados de experimentos, etc.
  

La medida de confianza se define de la siguiente manera:

• 5 – Strong Research Support
  
  
  • Cumulative and compelling, supporting research-based evidence
  • At least one formal, rigorous study with contextual validity
  • No known conflicting research-based findings
  • Expert opinion agrees with the research
• 4 – Moderate Research Support
  
  
  • Cumulative research-based evidence
  • There may or may not be conflicting research-based findings
  • Expert opinion
  • Tends to agree with the research, and
  • A consensus seems to be building
• 3 – Weak Research Support
  
  
  • Limited research-based evidence
  • Conflicting research-based findings may exist
  - and/or -
  • There is mixed agreement of expert opinions
• 2 – Strong Expert Opinion Support
  
  
  • No research-based evidence
  • Experts tend to agree, although there may not be a consensus
  • Multiple supporting expert opinions in textbooks, style guides, etc.
  • Generally accepted as a ’best practice’ or reflects ’state of practice’
• 1 – Weak Expert Opinion Support
  
  
  • No research-based evidence
  • Limited or conflicting expert opinion

En el apéndice de la guía encontramos lo que puede servirnos de checklist (PDF 20.64 MB), que es el listado de todas las directrices agrupadas por su importancia.

Se puede consultar una comparativa entre la ISO 9241-151 y las HHS Guidelines en BEVAN, N. , SPINHOF, L. (2007): "Are guidelines and standards for web usability comprehensive?" (PDF)

247 directrices de usabilidad web de Userfocus

Userfocus propone 247 directrices de usabilidad que distribuye en 9 heurísticos:

• Usabilidad de la página de inicio (20 directrices)
• Orientado a tareas (44 directrices)
• Navegación y Arquitectura de Información (29 directrices)
• Formularios y entrada de datos (23 directrices)
• Confianza y credibilidad (13 directrices)
• Escritura y calidad de los contenidos (23 directrices)
• Esquema de la página (layout) y diseño visual (38 directrices)
• Usabilidad en la búsqueda (20 directrices)
• Ayuda, feedback y tolerancia a errores (37 directrices)

Una gran ventaja es que ofrece gratuitamente una excel de trabajo con las 247 directrices (traducida al español) que facilita la valoración y la inclusión de comentarios.

Nielsen Norman Group Guidelines

Posiblemente los 10 heurísticos de Jakob Nielsen sean los más conocidos:

1. Visibilidad del estado del sistema.
2. Utilizar el lenguaje de los usuarios.
3. Control y libertad para el usuario.
4. Consistencia y estándares.
5. Prevención de errores.
6. Minimizar la carga de la memoria del usuario.
7. Flexibilidad y eficiencia de uso.
8. Los diálogos estéticos y diseño minimalista.
9. Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores.
10. Ayuda y documentación.

Según el propio Jakob Nielsen dispone de 2397 directrices de usabilidad repartidas en múltiples informes que lista en "Publications" de nngroup.com

Swedish National Guidelines for Public Sector Websites

La guía del Gobierno de Suecia Swedish National Guidelines for Public Sector Websites es especialmente completa. Las directrices están agrupadas por capítulos, dentro de los cuales se listan los heurísticos y las directrices asociadas.

Aunque no incluye checklists asociadas, las directrices están muy bien explicadas y tienen asociadas un nivel de prioridad (1, 2 y 3, siendo las de nivel 1 las más críticas)

En el capítulo "3. Website standards" se incluyen 58 directrices agrupadas en:

• Estructura y navegación (9 directrices)
• Color, contraste y tipografía (3 directrices)
• Diseño (22 directrices)
• Tablas de datos (5 directrices)
• Formularios (11 directrices)
• Aplicaciones web (3 directrices)
• Manejo de errores (3 directrices)
• Eventos del sistema (2 directrices)

En el capítulo Contenidos y servicios se incluyen 29 directrices agrupadas en:

• Acerca de la autoridad (5 directrices)
• Información básica (8 directrices)
• Otros lenguajes (3 directrices)
• Búsqueda (4 directrices)
• Distribución de servicios y contenidos del sitio web (4 directrices)
• Participación y transparencia (5 directrices)

En el capítulo Actualización del sitio web (o mantener el sitio al día) se incluyen 43 directrices agrupadas en:

• Administración (1 directrices)
• Seguimiento del uso y el contenido (6 directrices)
• Información de "emergencia" en el sitio (6 directrices)
• Escribir para la web (9 directrices)
• Formato de la web (marcado HTML) (9 directrices)
• Imágenes y gráficos (4 directrices)
• Enlaces y documentos (8 directrices)

Hay otros capítulos como "Servicio mejor y más eficiente", "Proceso de desarrollo", "Contenido para dispositivos móviles", "Herramientas de publicación" o "Productos de apoyo para usar el sitio web".

Sirius

La propuesta de Mª del Carmen Suarez en su tesis Sirius: Sistema de Evaluación de la Usabilidad Web Orientado al Usuario y basado en la Determinación de Tareas Críticas (PDF, 3.39 MB) son 83 directrices dividas en:

• Aspectos generales (10 directrices)
• Identidad e información (7 directrices)
• Estructura y navegación (14 directrices)
• Rotulado (6 directrices)
• Layout de la página (10 directrices)
• Entendibilidad y facilidad en la interacción (7 directrices)
• Control y retroalimentación (10 directrices)
• Elementos multimedia (6 directrices)
• Búsqueda (8 directrices)
• Ayuda (5 directrices)

Hablé de su sistema en profundidad en Sirius. Nuevo sistema para la evaluación de la usabilidad web. Su método presenta numerosas ventajas, por ejemplo que la relevancia de los errores tienen en cuenta el tipo de sitio evaluado.

Permite elaborar una herramienta de evaluación que dé soporte al sistema planteado y facilite la validación empírica de la propuesta de evaluación. Proporcioné esta herramienta en formato excel: Checklist para la evaluación de la usabilidad web según la metodología Sirius. Versión 3 (XLSX)

Australia Government Usability Checklist

La Australia Government Usability Checklist es la más sencilla de todas las vistas hasta ahora. Está incluida dentro del conjunto de publicaciones "User Profiling and Testing Tollkit" del Gobierno de Australia.

Son 43 directrices clasificadas en 6 temas:

• Arquitectura y navegación
• Layout y diseño
• Contenidos
• Formularios
• Plataforma e implementación
• Accesibilidad (prioridad 1)

Guía para el Desarrollo de Sitios Web del Gobierno de Chile

Al igual que la del Gobierno de Australia, presenta una checklist de usabilidad bastante reducida.

Son 30 directrices divididas en los siguientes heurísticos:

• Identidad corporativa
• Utilidad del sitio web
• Navegación
• Visibilidad del estado del sistema
• Consistencia y cumplimiento de estándares
• Atención a errores
• Estética y diseño
• Ayuda a errores
• Retroalimentacion (feedback)

Usability Guidelines del MIT (Massachusetts Institute of Technology)

En la web IST (Information Services & Technology) del MIT (Massachusetts Institute of Technology) encontramos el apartado "Usability at MIT" con numerosos recursos de interés.

Uno de estos recursos son las "Usability Guidelines", 62 directrices agrupadas en:

• Navegación (5 directrices)
• Funcionalidad (4 directrices)
• Control del usuario (5 directrices)
• Lenguaje y contenido (7 directrices)
• Ayuda en línea y guías de usuario (2 directrices)
• Feedback (7 directrices)
• Accesibilidad (14 directrices)
• Consistencia (2 directrices)
• Prevención y correción de errores (8 directrices)
• Claridad arquitectual y visual (8 directrices)

Directrices de usabilidad para sitios web del Estado colombiano

En 2010 M. Carvajal y J. Saab (2010) publicaban un documento muy interesante: “Documento de análisis de prácticas y recomendaciones mundiales en Usabilidad (PDF)” para el Ministerio de Tecnologías de la Información y las Comunicaciones de la República de Colombia. En él se repasan diferentes propuestas de diferentes países para concluir cuál sería la mejor forma de redactar unas recomendaciones de usabilidad para el Gobierno de Colombia.

Actualmente encontramos una versión 1.0.4 candidata a oficial (del 26 de agosto de 2010) en Directrices de usabilidad para sitios web del Estado colombiano (PDF, 4.1 MB).

Las directrices están organizadas así:

• 1. Arquitectura de información
  
  
  • 1.1 Objetivos del portal web
  • 1.2 Personajes y escenarios
  • 1.3 Necesidades de los usuarios
  • 1.4 Evaluación constante
  • 1.5 Evaluación de la Arquitectura de Información
  • 1.6 Navegación global consistente
  • 1.7 Navegación de contexto
  • 1.8 Ruta de migas
  • 1.9 URL limpios
  • 1.10 Ubicación del usuario
  • 1.11 Tagline
  • 1.12 Enlaces bien formulados
  • 1.13 Memoria a corto plazo
• 2. Diseño de Interfaz de Usuario
  
  
  • 2.1 Ubicación del logotipo
  • 2.2 Diseño ordenado y limpio
  • 2.3 Interfaces en movimiento
  • 2.4 Contenido que parece publicidad
  • 2.5 Contraste en brillo y color
  • 2.6 Información transmitida a través de color
  • 2.7 Justificación del texto
  • 2.8 Ancho del cuerpo de texto
  • 2.9 Fuentes tipográficas comunes
  • 2.10 Texto subrayado
  • 2.11 Uso adecuado del espacio en blanco
  • 2.12 Desplazamiento horizontal
  • 2.13 Vínculo a la página de inicio
  • 2.14 Tareas clave en la página de inicio
  • 2.15 Contenidos de ejemplo en la página de inicio
  • 2.16 Hojas de estilo para diferentes formatos
  • 2.17 Independencia de navegador
  • 2.18 Vínculos visitados
  • 2.19 Calidad del código

Otro documento recomendable de M. Carvajal es La Guía Web 1.0 de Proexport (PDF) donde se aplican las directrices.

Otros enlaces de interés

En Index of Government Guidelines for Web Sites de Peter Krantz se puede encontrar las guías web de los diferentes gobiernos en el mundo. Algunas de interés que no he nombrado son:

• Las Kwaliteitsmodel Webrichtlijnen (The Web Guidelines quality model) son las las directrices del Gobierno de Holanda. Están centradas en la accesibilidad y el uso adecuado del estándar HTML
• Las Elmer 2: User interface guidelines for governmental forms on the Internet (PDF), es una guía del Gobierno de Noruega con una checklist muy interesante pero está centrada exclusivamente en los formularios web.
• Tasmanian Government Web Usability Guidelines 2009 recoge diversos documentos pero no tienen directrices asociadas como hemos podido ver en otros casos.

El artículo "Official Usability, User Experience & User Interface Guidelines From Companies" de usabilitygeek.com, repasa las diferentes guías de directrices de compañías concretas (Adobe, Apple, IBM, Microsoft, etc.) aunque la que más me gusta es la de SUN, pero la de 1995: Sun Guide to Web Style

Artículos anteriores

• Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística
• iPad, recomendaciones de usabilidad para tu web
• Formularios usables: 60 Directrices de Usabilidad
• Wireframes
• HTML 5 y accesibilidad

Os dejo el enlace a la entrevista que me han hecho en Límit nord-est.

Entrevista amb Olga Carreras

El objetivo de este artículo es explicar cómo podemos tener una descripción extensa de una imagen en la propia página, de tal manera que:

• sea accesible para los lectores de pantalla
• se visualice cuando la imagen no esté cargada (bien porque tenemos las imágenes desactivadas, bien porque ya no se encuentra disponible, etc.)

Todo ello sin depender del atributo longdesc, que no siempre es soportado, ni de los típicos enlaces [D] junto a la imagen (conocidos como D-Link); y asegurando que no dé problemas cuando se deshabilita el javascript o las CSS.

Este artículo se me ocurrió después de leer el artículo de Steve Faulkner Detecting if images are disabled in browsers, en el cual explicaba cómo podemos detectar por javascript si las imágenes están deshabilitadas o no se han cargado.

HTML

El código HTML es XHTML 1.0 Strict válido y es el siguiente. En primer lugar tenemos la cabecera:

Como se ve, estoy llamando a una CSS y a un JS que explico más adelante.

A continuación tenemos el cuerpo de la página:

Después de lo que es el título de la página y el enlace al artículo tenemos ya la imagen:

La imagen es un gráfico, por tanto el atributo ALT no es suficiente, necesitamos una descripción detallada la imagen.

Os preguntaréis la razón por la cuál he incluido a continuación de la imagen un enlace "Ver descripción de la imagen".

Como vemos, a continuación se incluye la descripción detallada correctamente maquetada. Esta descripción se oculta una vez cargada la página mediante javascript no intrusivo, por tanto estará disponible tanto sin javascript activo como sin CSS activas, debajo de la imagen.

Con CSS activas, tanto si pulsas el enlace como si no se carga la imagen, la descripción se posiciona a la derecha de la imagen.

Por otro lado veremos que la descripción extensa se está ocultando de forma accesible, así que los usuarios que usan un lector de pantalla (podéis probarlo con NVDA) escuchan la descripción a continuación de la imagen y el enlace.

En el pie de la página os recuerdo que si deshabilitáis el javascript, las CSS o las imágenes mientras visualizáis la página deberéis recargarla. Para facilitaros comprobar que, efectivamente, cuando no se carga la imagen se muestra por defecto la descripción a su lado, os pongo un enlace a una copia de la página donde he escrito mal el nombre de la imagen para comprobar cómo se ve la página sin la imagen cargada.

Como se observa, cuando la imagen no se ha podido mostrar, se ve en el hueco que ocuparía la imagen su ALT, y junto a la imagen aparece por defecto la descripción detallada. Ya no se muestra el enlace "Ver descripción de la imagen" porque no es necesario.

CSS

La CSS es CSS 2.1 válida. No pongo toda la CSS, sólo aquello que es relevante para el ejemplo.

Con esta clase general "oculto" oculto aquellos elementos que me interesa:

• al cargarse la página compruebo si la imagen se ha cargado, en cuyo caso oculto por javascript la descripción. Sin javascript activo, por tanto, la descripción se verá.
• el enlace "Ver descripción de la imagen" tiene esta clase "oculto" por defecto y una vez cargada la página lo hago visible. De esta manera, sin javascript activo, el enlace no se muestra puesto que ya no es necesario.

La forma de ocultar (mediante posicionamiento fuera de pantalla) permite que los lectores de pantalla sí puedan acceder al contenido oculto, algo que no ocurre con display:none. Más detalles en "Ocultar contenido sin comprometer la accesibilidad ni el posicionamiento de la página"

Otros estilos que me interesa comentar son los de la imagen:

Por defecto indico que el ancho de las imágenes sea "auto". No puedo poner por defecto el tamaño real de la imagen porque el script se basa en comprobar si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no está cargada.

Sin embargo tengo una clase con el tamaño real de la imagen porque en Safari y Chrome, si la imagen no tiene especificado su ancho y alto real, no se muestra su atributo ALT. Así que veremos que en el script, tras comprobar el ancho de la imagen para saber si la imagen está cargada, le aplico la clase "widthImage1", y de este modo en Safari y Chrome vemos su ALT.

JS

La función "addLoadEvent" es la que nos permite llamar a funciones en el onLoad de la página de forma no intrusiva.

¿Qué funciones estamos llamando? Primero a addLoadEvent(noimage)

Lo primero que hago, como ya he comentado, es ocultar la descripción larga de la imagen y mostrar el enlace "Ver descripción de la imagen".

A continuación compruebo si el ancho de la imagen es diferente del ancho que debería tener, en cuyo caso es que la imagen no se ha cargado.

Nota: Faulkner lo comparaba con 1 porque no le ponía ALT a las imágenes. Entonces el hueco de la imagen no se adaptaba al ALT y por eso su ancho era 1 cuando no estaba cargada. Como se debe poner ALT tenemos que hacerlo comparándolo con su ancho real. Por otro lado, indicar el ancho y alto de la imagen ayuda a las personas que ven la página sin la imagen cargada a hacerse una idea del tamaño que esta tenía.

En el caso de que la imagen no se haya cargado muestro la descripción, cambio la clase de la CSS aplicada a la imagen (ya he explicado en la CSS que es para que en Chrome y Safari se vea el atributo ALT dentro de la zona de la imagen) y oculto el enlace "Ver descripción de la imagen" porque el enlace ya no es necesario.

La otra función que llamo en el onLoad de la página es la siguiente:

Esta función añade al evento "onClick" del enlace "Ver descripción de la imagen" una función que:

• Si la descripción de la imagen está oculta, al pulsar el enlace la mostraremos. Y a continuación cambiaremos el texto del enlace por su nueva acción "Ocultar descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de ocultar la descripción.
• Si la descripción de la imagen está visible, al pulsar el enlace la ocultaremos. Y a continuación cambiaremos en texto del enlace por su nueva acción "Ver descripción de la imagen" y cambiaremos también el TITLE de la imagen para que esté acorde con su nueva función de mostrar la descripción.

Os animo ha que dejéis en los comentarios cualquier sugerencia de mejora o problema que detectéis.

Artículos relacionados:

• Asociación compleja de radios y labels de forma accesible
• Qué teclas de acceso rápido (accesskey) utilizar
• Formulario con varios botones. Implementación usable y accesible
• AJAX accesible
• Enlaces que actúan como botones. Implementación accesible.

El 27 de marzo (de 2012) el W3C/WAI publicó el primer borrador de la "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)" (según la traducción que hace la nota de prensa del W3C España), en inglés "Website Accessibility Conformance Evaluation Methodology 1.0".

Este borrador de trabajo es un primer esbozo y, como se indica, puede ser actualizado, reemplazado o quedar obsoleto en cualquier momento. Por otra parte algunas de sus secciones están todavía sin desarrollar. Sin embargo, es un documento de gran interés para los consultores de accesibilidad que solo está disponible en inglés. El objetivo de este artículo es difundirlo y resumirlo en castellano, actualizándolo a medida que se publiquen nuevas versiones.

Hasta el 27 de abril se pueden enviar comentarios sobre este primer borrador, que son públicos y se pueden consultar en "public-wcag-em-comments@w3.org Mail Archives". El 20 de septiembre de publicó la última actualización del documento.

Debido a que generalmente no es factible ni conveniente evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar la conformidad global de un sitio web. En el documento se especifican los pasos concretos para definir el alcance de la evaluación, seleccionar una muestra representativa, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Esta metodología se utiliza para una exhaustiva evaluación de la conformidad de sitios web de acuerdo sobre las WCAG 2.0 Para la revisión preliminar de un sitio que permita identificar los errores más evidentes recomiendan "Preliminary Review of Websites for Accessibility", publicado en la web de la WAI

La metodología se aplica siempre a un sitio web completo sin exclusiones u omisiones de páginas que sirvan a la finalidad y funcionalidad del sitio, y que por tanto forman parte de la navegación, el diseño y los procesos completos del sitio. Sin embargo sí que se permite aplicar a ámbitos claramente separables de un único sitio web, como podría ser la parte pública y la parte privada del mismo.

Se especifica el conocimiento que debería tener el evaluador y que se puede resumir en un profundo conocimiento de las WCAG 2.0, sobre cómo evaluar la accesibilidad y sobre el diseño de web accesibles, y por tanto conocedores de los siguientes recursos:

• "Evaluating Websites for Accessibility", una suite de documentos de la WAI que constituye la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos. Lo traté con detenimiento en el artículo "Metodología para la evaluación de la accesibilidad Web: 'Evaluating Web Sites for Accessibility' de la WAI "
• Web Content Accessibility Guidelines (WCAG) 2.0, y todos los documentos asociados ("How to Meet WCAG 2.0 (Quick Reference)", "Understanding WCAG 2.0" y "Techniques for WCAG 2.0")
• Accessible Web Design (Designing for Inclusion), y que incluye documentos como: "Essential Components of Web Accessibility", "How People with Disabilities Use the Web", "Developing Websites for Older People", "Web Content Accessibility and Mobile Web" o "Involving Users in Web Projects for Better, Easier Accessibility".

La metodología puede ser llevada a cabo por un evaluador de forma individual o por un equipo de revisión. Se indica que la participación de personas con discapacidad y de personas mayores, aunque no es obligatoria, ayuda a identificar barreras de accesibilidad adicionales.

Tras esta introducción, que se corresponde con un resumen de los apartados 1 y 2 de la WCAG-EM, en el apartado 3 se definen los pasos del procedimiento de evaluación.

Se indica que los detalles de estos pasos pueden variar ligeramente dependiendo del tipo de sitio, el propósito de la evaluación, y el proceso utilizado por el evaluador. Algunos de los pasos también pueden solaparse o llevarse a cabo en paralelo, pero es importante que se tengan en cuenta todos los pasos para garantizar una evaluación fiable. También es importante documentar claramente cada paso para garantizar unos resultados verificables y justificar la declaración de conformidad.

Los pasos son:

Paso 1. Definir el alcance de la evaluación

El alcance se debería definir de acuerdo con quienes han encargado la evaluación para asegurar unas expectativas comunes. Se divide en los siguientes subpasos:

• Paso 1a: definir el alcance exacto sin contradecir las limitaciones que se han indicado en el ámbito de aplicación de la metodología. Esto puede requerir conocer la propiedad o el proceso de desarrollo de algunas partes del sitio, y tener que llevarse a cabo a la vez que el paso 2 (navegar por el sitio web)
• Paso 1b: definir el objetivo de la evaluación, que puede ser:
  
  
  • Basic conformance: sólo se identifica si un sitio es o no conforme sin proporcionar información adicional (adecuado por ejemplo si solo se quiere verificar la declaración de conformidad)
  • Detailed review: identifica si un sitio web es o no conforme y se proporciona más información sobre los errores identificados, como puede ser el número de errores y su ubicación.
  • In-Depth analysis: identifica si un sitio web es o no conforme y se analizan con detalle los errores identificados, incluyendo la descripción de los errores y las sugerencias de soluciones.
  • Other: se puede establecer otro objetivo pero debe definirse claramente y con exactitud.
• Paso 1c: definir cuál el nivel de adecuación (A, AA, AAA) que se va a evaluar, que puede ser AAA aunque el objetivo a alcanzar sea el nivel A o AA (para tener una visión más completa de la accesibilidad del sitio o para mejorar tipos de contenidos concretos: las tablas, formularios, etc.)
• Paso 1d: definir el contexto de uso del sitio web, quién lo usa y cómo lo usa. Es importante identificar si es un sitio público o no (por ejemplo una intranet) Se debe definir el conjunto mínimo de navegadores web y productos de apoyo con los que se va a realizar la evaluación (y que puede variar significativamente en función de si es un sitio público o una intranet, según el idioma, la ubicación geográfica o el público objetivo del sitio)
• Paso 1e (opcional): definir las técnicas a utilizar que pueden ser las definidas en "Techniques for WCAG 2.0" pero no obligatoriamente estas. Este paso se puede superponer con el paso 2 (explorar el sitio web), y en todo caso las técnicas exactas que se han usado para evaluar la conformidad con las WCAG 2.0 deben estar documentadas en el paso 5 (informar de los resultados de la evaluación)

Paso 2. Explorar el sitio web

El evaluador debe poder acceder a todas las páginas. Este paso permite comprender mejor el uso y funcionalidad del sitio; y además ayuda a identificar las páginas relevantes o con problemas que son candidatas a incluirse en la muestra a analizar.

Se divide en los siguiente subpasos:

• 2a: identificar las páginas clave del sitio. Se indican como tales: la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas (cabecera, pie o menú de navegación); así como las diferentes plantillas
• 2b: identificar las funcionalidades clave del sitio, incluyendo las tareas que los usuarios deben llevar a cabo para realizar una funcionalidad (por ejemplo, "selección y compra de un producto", "registrar una cuenta en el sitio", etc.)
• 2c: identificar diferentes tipos de páginas (no plantillas como en el paso 2a), con diferentes estilos, layout, estructuras y funciones, que a menudo son generadas por diferentes plantillas y escritas por diferentes personas:
  
  
  • Páginas web con diferentes estilos, layout, estructura, navegación, interacción y diseño visual;
  • Páginas con contenido diverso, como los formularios, tablas, listas, encabezados, multimedia y scripts;
  • Páginas con diferentes componentes funcionales, tales como selector de fechas, lightbox, slider, y otros;
  • Páginas que utilizan diversas tecnologías, tales como HTML, CSS, Flash, JavaScript, PDF, Silverlight y WAI-ARIA;
• 2d: identificar las tecnologías de las que se depende (según el concepto de las WCAG 2.0: el contenido no puede ser conforme si dicha tecnología se desconecta o no es soportada), que pueden ser HTML, CSS, Flash, JavaScript, PDF, Silverlight, WAI-ARIA, SMIL, SVG, etc.

Paso 3. Seleccionar una muestra representativa

Se debe seleccionar una muestra de páginas que represente a todo el sitio. El tamaño de la muestra dependerá del tamaño y complejidad del sitio.

Los subpasos de los que se compone son:

• 3a: incluir las páginas principales del sitio. Tienen que formar parte de la muestra todas las plantillas y todas las páginas relevantes (la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas como la cabecera, pie o menú de navegación) identificadas en el paso 2a.
• 3b: incluir al menos dos páginas diferentes (si procede) de las identificadas en:
  
  
  • el paso 2b: páginas con funcionalidades clave
  • el paso 2c: diferentes tipos de páginas
  • el paso 2d: páginas con diferentes tecnologías

  En sitios complejos puede hacer falta seleccionar más de dos páginas de cada tipo; otras veces una misma página puede ser representativa de varias de estas características.

  Debería seguirse siempre este proceso de selección, aunque en re-evaluaciones puede ser útil seleccionar parte de la muestra de una evaluación anterior para comparar el resultado.

• 3c: incluir otras páginas relevantes para la accesibilidad o las personas con discapacidad:
  
  
  • Páginas con información y ayuda sobre el uso de la página web o pertinentes para la accesibilidad;
  • Páginas especialmente populares y las que se utilizan comúnmente como páginas de entrada al sitio;
  • Mensajes de error del servidor web (por ejemplo, la página de error 404) o de una aplicación web;
• 3d: incluir en la muestra procesos completos. Es decir, todas las páginas de un proceso, no se puede seleccionar solo una página del proceso.

Paso 4. Auditar la muestra seleccionada

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

• 4a: comprobar para la más amplia variedad de casos de uso
• 4b: utilizar cuando sea posible las "WCAG 2.0 Techniques"
• 4c: evaluar la accesibilidad según las técnicas utilizadas y las características de accesibilidad identificadas
• 4d (opcional): archivar las páginas auditadas (en un pantallazo, guardando una copia, etc.) para futuras referencias o controversias.
• 4e (opcional): registrar las herramientas y métodos de evaluación

Paso 5. Informar de los resultados de la evaluación

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

• 5a: proporcionar documentación para cada paso
• 5b (opcional): proporcionar una declaración de accesibilidad
• 5c (opcional): proporcionar una puntuación
• 5d (opcional): proporcionar información sobre los errores identificados
• 5e (opcional): proporcionar sugerencias para solucionar los errores
• 5f (opcional): proporcionar un informe legible por máquinas (como EARL)

Plantilla para el informe

El objetivo del apéndice C es ofrecer un ejemplo de plantilla, con la idea de tener tres diferentes niveles de presentación de informes. Se ofrece un ejemplo por cada uno de los objetivos posibles de la evaluación especificados en el paso 1b.

En el caso más completo, los contenidos que debería ofrecer el informe serían:

• Resumen
• Terminología
• Fecha de la declaración de conformidad y validez en el tiempo
• Fecha de la evaluación
• Persona que hizo la evaluación
• Directrices, versión y URI: "Web Content Accessibility Guidelines 2.0 en http://www.w3.org/TR/2008/REC-WCAG20-20081211/"
• Nivel de conformidad testeado (A,AA,AAA) y si dicho nivel de conformidad es satisfecho
• Descripción concisa de las páginas, con una lista de URI para las cuales se hace la declaración, indicando si los subdominios están incluidos en la declaración
• Lista de los criterios de conformidad cumplidos más allá del nivel de conformidad alcanzado
• Descripción del sitio que ha sido evaluado, incluyendo una descripción general de lo que está y no está incluido
• Listado de las tecnologías de las que se depende y una lista de aquellas que están excluidas de la evaluación (pero disponibles en el sitio evaluado)
• Declaración parcial de conformidad (si se trata de una evaluación de conformidad)
• Resultados, por cada directriz y criterio de conformidad, indicando:
  
  
  • si lo pasa o no
  • la frecuencia y alcance del problema, si se da en toda la muestra o el listado de páginas en el que se encuentra
  • descripción de los problemas existentes y las barreras para los usuarios o enlaces a estas descripciones en la web del W3C/WAI
  • descripción de las técnicas
  • listado de agentes de usuario, incluidos productos de apoyo, que se utilizaron durante la evaluación, indicando su versión
  • listado de las páginas de la muestra
• Disclaimer

Artículos relacionados:

• Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España
• Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI
• Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA
• Reseña "Just Ask: Integrating Accessibility Throughout Design"
• Herramienta de ayuda para realizar una consultoría de accesibilidad de acuerdo a las WCAG 1.0/Norma UNE 139803
• Herramienta de ayuda para realizar una consultoría de accesibilidad de acuerdo a las WCAG 2.0

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

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:

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

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

Artículos relacionados:

• Respuesta a 25 dudas habituales sobre accesibilidad web
• Consejos avanzados de accesibilidad web
• WCAG 2.0

Artículos relacionados:

• iPad, recomendaciones de usabilidad para tu web
• HTML 5 y accesibilidad
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

Índice

• Iniciativa Web Móvil (MWI) del W3C
• Mobile Web Best Practices 1.0 (MWBP)
• Mobile Web Application Best Practices
• Guías específicas de accesibilidad para el desarrollo de apps nativas en diferentes dispositivos
• ¿Cómo usan las personas con discapacidad un dispositivo móvil?
• Otras referencias sobre UX en dispositivos móviles
• Conclusiones

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.

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:

  • Mobile Web Best Practices (recomendación desde julio de 2008)
  • Mobile Web Application Best Practices (recomendación desde diciembre de 2010)

  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.)

   

• 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.

Imagen de The W3C mobileOK™ Checker, W3C

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:

Consultar "W3C mobileOK Logo and Policy"

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

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):

• From MWBP to WCAG 1.0: si tu sitio ya cumple con las MWBP cómo cumplir también con las WCAG 1.0
• From MWBP to WCAG 2.0: si tu sitio ya cumple con las MWBP cómo cumplir también con las WCAG 2.0
• From WCAG 1.0 to MWBP: si tu sitio ya cumple con las WCAG 1.0 cómo cumplir también con las  MWBP
• From WCAG 2.0 to MWBP: si tu sitio ya cumple con las WCAG 2.0 cómo cumplir también con las MWBP

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:

• Guía de Accesibilidad en los contenidos para dispositivos móviles, Inteco
• Guidelines for the development of accessible mobile interfaces, PDF (270 kb), Swedish Internet Fund
• Global Authoring Practices for the Mobile Web, Luca Passani, buenas prácticas para la creación de servicios móviles usables basados en XHTML-Mobile Profile 1.0

• Sobre el soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles es interesante conocer dos artículos de Henny Swan:

  • Screen reader support for abbr and span on mobile
  • Use consistent text alternatives across desktop and mobile

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

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.

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:

• Accessibility Application Development. Describe los diferentes métodos disponibles en Windows Embedded CE para establecer las opciones de accesibilidad.
• Accessibility Reference. Proporciona una descripción de los elementos de accesibilidad de programación.

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"

Otras referencias sobre UX en dispositivos móviles

• Usability of Mobile Websites & Applications: 237 Design Guidelines for Improving the User Experience of Mobile Sites and Apps, de Jakob Nielsen. Es la segunda edición, en la primera sólo había 85 directrices.
• Mobile Web Developers's Guide(PDF), en general la web mobiForge tiene contenidos de interés.
• Usability of iPad Apps and Websites, de Jakob Nielsen.
• User experience checklist for touch (PDF). UX Checklist de Nokia para dispositivos táctiles
• User experience checklist for keypad (PDF). UX Checklist de Nokia para dispositivos con teclado
• Usabilidad en dispositivos táctiles, de Xperience Consulting
• Mobile Web Site Guidelines, de la Universidad de Texas
• Mobile UI Patterns
• 20+ Mobile Apps Inspiration and Design Pattern Galleries

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:

• iPad, recomendaciones de usabilidad para tu web
• HTML 5 y accesibilidad
• Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

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

• Entra en vigor la “ley de cookies” en España, Eduard Barredo, 04/04/2012
• Cómo cumplir con la nueva ley de cookies (parte I), Sergio Maldonado, 19/04/2012
• Cómo cumplir con la nueva ley de cookies (parte II). Ejemplo práctico, Sergio Maldonado, 20/04/2012

Si os interesa conocer un poco más de mí, hoy Chema Rodriguez me entrevista en la contraportada del Heraldo de Aragó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:

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

• Los Artículos, buenas prácticas & tutoriales de la web del Internationalization Core Working Group<(a href="http://www.w3.org/International/" lang="en">W3C Internationalization (l18n) Activity). Se puede acceder al Índice de técnicas y el Índice de temas, que ofrecen un acceso más preciso a la información.
• El documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content, del Internationalization Core Working Group (parte del W3C Internationalization Activity) El documento es de 2007 y en él se describen 16 buenas prácticas.

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:

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:

• Accesibilidad y usabilidad móvil: web móvil y app nativa
• Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística
• Arquitectura de información. Fundamentos
• Sirius. Nuevo sistema para la evaluación de la usabilidad web

A principio de año compartía con vosotros dos herramientas personales de ayuda para realizar una consultoría de accesibilidad web:

• Herramienta de ayuda para realizar una consultoría de acuerdo a las WCAG 1.0 y la Norma UNE 139803:2004
• Herramienta de ayuda para realizar una consultoría de acuerdo a las WCAG 2.0

Gracias a la colaboración de Roberto Muñoz y alumnos de la Facultad de Ingeniería de la Universidad de Valparaíso, Chile, comparto con vosotros una nueva versión de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0

La herramienta, tal y como la describía en los artículos anteriores citados, permite ir recogiendo los datos obtenidos durante la revisión automática y manual del sitio de acuerdo a las WCAG 2.0

La herramienta genera automáticamente información de utilidad para el apartado de resumen ejecutivo que debería incluirse en el informe final para el cliente: un resumen del nivel de adecuación A y AA (tanto de la muestra en general como de cada una de sus páginas) datos estadísticos y gráficas que permiten resumir y presentar de forma concisa y muy gráfica los resultados. También nos ayuda a nosotros a identificar con rapidez cuáles son los criterios de conformidad y las páginas que presentan más problemas.

Las novedades de la versión 2.0 son dos nuevas hojas en la excel:

• Hoja de la excel "Resumen": incluye la recopilación de las tablas resumen de las hojas anteriores, por cada página de la muestra (y la muestra en su conjunto), cada nivel de adecuación y cada uno de los cuatro principios.

• Hoja de la excel "Tabla resumen": tabla y gráficas resumen con el promedio de cumplimiento por nivel de adecuación y principio.

Toda esta información también resulta muy útil para comparar en el tiempo el nivel de accesibilidad de una misma web, o comparar el nivel de accesibilidad de diferentes portales de, por ejemplo, un mismo sector.

Artículo actualizado el 16/7/2012 tras la lectura de la Norma UNE 139803:2012

El 4 de julio de 2012 se publicó la actualización de la Norma UNE 139803:2004, la AEN/CTN 139/SC 8: UNE 139803:2012 'Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos en la Web', que anula y sustituye a su predecesora.

Los requistos de la Norma UNE 139803:2004 estaban basados en las WCAG 1.0, sin embargo, la Norma UNE 139803:2012 es equivalente a las WCAG 2.0

Es un documento de 28 páginas, que de momento no es gratuito: cuesta 32.58 euros

La Norma UNE 139803:2012

El problema de la Norma UNE 139803:2004 es que reinterpretaba las WCAG 1.0 e incluso algunos de sus requisitos cambiaban de prioridad respecto a las WCAG 1.0

Sin embargo, la Norma UNE 139803:2012 hace referencia directamente a las WCAG 2.0 No reproduzco el contenido, porque está prohibido, pero comento su alcance.

Los requisitos de nivel A, AA y AAA son los criterios de conformidad de nivel A, AA y AAA de las WCAG 2.0, a los que se referencia directamente sin reescribirlos. Para cumplirlos se deberá tener en cuenta también el documento de apoyo de las WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0

De la misma manera, los requisitos de conformidad y las características de la declaración de conformidad son los mismos que en las WCAG 2.0, a los que se referencia directamente.

Es muy útil el Anexo B, una guía para pasar de la Norma UNE 139803:2004 a la Norma UNE 139803:2012, con una tabla de correspondencias explicada detalladamente.

¿Qué implicaciones tiene?

La Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información (LISI) establece que a partir de 2009 tienen la obligación de crear contenidos accesibles:

• la Administración Pública
• las entidades y empresas que se encarguen de gestionar servicios públicos empresas privadas que reciban financiación pública
• las empresas con más de 100 trabajadores o que facturen más de 6 millones de euros, especialmente las entidades bancarias, las aseguradoras, las agencias de viaje, las empresas de transporte, las suministradoras de gas, agua y electricidad, las empresas de telecomunicaciones y las grandes superficies

En 2011 con la Ley 26/2011, de 1 de agosto, de adaptación normativa a la Convención Internacional sobre los Derechos de las Personas con Discapacidad, se incluyen también las redes sociales (desarrolladas por entidades cuyo volumen anual de operaciones sean mayor a 6 millones de euros)

En el Real Decreto 1494/2007, de 12 de noviembre, se establece el nivel de adecuación que deben cumplir. Indica que como mínimo deben cumplir con el nivel AA de la Norma UNE 139803“Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos en la Web”.

Por su parte, la ley 49/2007, de 26 de diciembre, establece las sanciones que van desde los 301 euros hasta el millón de euros por el incumplimiento.

Norma ISO/IEC 40500

Las WCAG 2.0 pronto serán también ya son (desde octubre de 2012) un estándar ISO a través de la Norma ISO/IEC 40500. Seguirán estando disponibles gratuitamente a través del sitio web del W3C. Los cambios futuros, fe de erratas y traducciones también seguirán siendo administrados a través de W3C/WAI.

Gracias a esto se espera que más países incluyan las WCAG 2.0 en su legislación, países que, como España, no pueden hacer referencia en sus leyes a normas que no hayan sido elaborada por un organismo oficial de estandarización.

Recursos para pasar de la Norma UNE 139803:2004/WCAG 1.0 a la Norma UNE 139803:2012/WCAG 2.0

• Documento de apoyo: Comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades, tradución al español del original del W3C
• Excel de correspondencia WCAG 1.0 / WCAG 2.0 / Norma UNE 139803:2004: Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0
• WCAG 2.0, de Olga Carreras
• Nueva versión de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0
• WCAG 2.0 Checklist
• Formularios accesibles según las WCAG 2.0
• Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

Artículos relacionados

• Referencia sobre legislación española relacionada con la accesibilidad web
• PDF Techniques for WCAG 2.0
• Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

Artículo relacionado:PDF/UA. Descripción de la norma. Comparativa y relación con las WCAG 2.0

El 7 de agosto de 2012 se publicó la norma ISO 14289-1:2012 Document management applications -- Electronic document file format enhancement for accessibility -- Part 1: Use of ISO 32000-1 (PDF/UA-1), tal y como anuncia el blog Adobe Accessibility.

Los que habéis asistido a mi curso de PDF accesibles recordaréis que aunque el formato PDF fue creado por Adobe, actualmente es un estándar formal y abierto: ISO 32000-1:2008 Document management -- Portable document format-- Part 1: PDF 1.7 y que existen diferentes estándares de PDF.

La ISO ha definido subconjuntos, cada uno de los cuales debe cumplir unos requisitos, y a estos se une ahora el PDF/UA.

Podemos guardar un PDF como PDF/A, cuyo nombre lleva a muchos a pensar que es un PDF accesible, pero que simplemente es un PDF pensado para que se conserve igual a largo plazo y que por ello debe cumplir con ciertos requisitos:

• PDF/A-1b: es el nivel más sencillo, requiere que sea 100% auto-contenido, es decir, que toda la información necesaria para mostrar el documento esté presente en el mismo: las fuentes, las imágenes, la información del color. No se puede incluir audio, vídeo, javascript o cifrado
• PDF/A-1a: requiere todos los requisitos de PDF/A-1b pero además obliga a que el documento esté estructurado y que utilice caracteres Unicode, que son requisitos de accesibilidad.

El PDF/A-1 está basado en PDF 1.4 Desde junio de 2011 tenemos la versión PDF/A-2 (PDF/A-2a, PDF/A-2b, PDF/A-2u) basado en PDF 1.7 Precisamente una de las ventajas de Adobe Acrobat X Pro frente a sus predecesores es que permite guardar como PDF/A-2

Además, en "Comprobaciones" podemos comprobar la compatibilidad de nuestro PDF con cualquiera de estos estándares:

Gracias a la publicación de la norma ISO 14289-1:2012, en versiones posteriores podremos guardar nuestros PDF como PDF/UA, que marca un hito en la evolución del formato PDF y esperemos que fomente la producción de PDF accesibles.

En el blog de Adobe Accesibility se indica que Adobe ha participado durante los 8 últimos años en el desarrollo de PDF/UA y están integrando su soporte en los productos de Adobe. También indican que han estado participando en el proyecto de código abierto del lector de pantalla NVDA para que soporte PDF/UA.

En el formato PDF/UA se recogen las características de la especificación PDF necesarias para la accesibilidad y se prohíbe cualquier función permitida por la norma ISO 32000-1:2008 pero que impiden la accesibilidad del PDF.

Es importante destacar que PDF/UA no es una especificación para evaluar la accesibilidad del contenido del PDF como lo son las WCAG 2.0 (ver PDF Techniques for WCAG 2.0), ni una guía de creación de PDF accesibles, sino que está dirigido a los desarrolladores de visores PDF y herramientas de creación de PDF, así como a los proveedores de productos de apoyo

Concretamente, el blog Adobe Accesibiliy indica que si solo eres autor de PDF accesibles no es necesario que compres la norma:

You don’t have to buy this standard if you just want to author accessible PDF files. However, you should encourage authoring tool makers, PDF viewer makers, and AT vendors to buy it, read it, and support it.

Aunque, evidentemente, sería muy recomendable que conocieras y leyeras ambas normas.

Artículos relacionados

• PDF/UA. Descripción de la norma. Comparativa y relación con las WCAG 2.0
• PDF Techniques for WCAG 2.0
• PDF accesibles
• PDF accesibles (2): metodología
• ePub accesibles

Servicios relacionados

• Curso "Creación de PDf accesible con Acrobat X Pro"
• Conversión de documentos PDF en PDF accesibles conforme a las WCAG 2.0 y la Norma UNE 139803: 2012

Apúntate al curso online y gratuito "iDESWEB, Introducción al desarrollo web" que comienza el 10 de septiembre, y en el que participo como profesora.

El curso es un MOOC (massive open online course), cuyo contenido pertenece a una asignatura que se imparte en tiempo real tanto a los alumnos matriculados en la Universidad de Alicante que la cursen de forma presencial, como a los alumnos que se apunten a http://www.idesweb.es

Se ha publicado mi vídeo "Prototipado" para el curso online y gratuito "iDESWEB: Introducción al desarrollo web" que comenzará el 10 de septiembre.

Transcripción del vídeo "Prototipado" (PDF, 48 kb)

Ver el vídeo "Prototipado" en YouTube

Artículos relacionados:

• Wireframes
• Arquitectura de información. Fundamentos

En la pauta 1.2 "Medios tempodependientes: Proporcionar alternativas para los medios tempodependientes" de las WCAG 2.0 se especifican los requisitos de accesibilidad que deben cumplir los contenidos "solo audio" (1), "solo vídeo" (2) y "multimedia sincronizado" (3), según si dicho contenido es "grabado" (4) o "en directo" (5).

A continuación os dejo una tabla resumen que os puede ser de gran utilidad para identificar con rapidez las alternativas que debéis proporcionar en función del nivel de conformidad deseado.

Hay que tener en cuenta que la pauta 1.2 indica que sólo son necesarias estas alternativas si el contenido tempodependiente no ofrece más información que la que ya se está ofreciendo mediante texto o alternativas textuales.

Aclaración 29/08/2012: una persona me ha preguntado por qué para cumplir con el nivel AA se exigía menos que para cumplir con el nivel A. ¡Ojo! Para cumplir con el nivel AA hay que cumplir con los requisitos de nivel A y con los de nivel AA, por tanto son acumulativos. De la misma manera, para cumplir con el nivel AAA, hay que cumplir con los requisitos de nivel A, AA y AAA.

Ver ejemplo: Multimedia accesible

Notas

(1) Solo audio: una presentación basada en el tiempo que contine únicamente audio (sin vídeo y sin interacción)

(2) Solo vídeo: una presentación basada en el tiempo que contine únicamente imágenes (vídeo), sin sonidos (audio) ni interacción

(3) Multimedia sincronizado: el audio o vídeo sincronizado con otro formato para presentar información y/o con componentes interactivos basados en el tiempo, excepto cuando se trata de un contenido multimedia alternativo al texto y está claramente identificado como tal (por ejemplo una película con vídeo y audio; un juego que aunque solo tenga vídeo o audio incluye interacción, etc.)

(4) Grabado: información que no es en directo

(5) En directo: la información capturada de un evento de la vida real y transmitida al receptor sin más demora que el retardo intencional de la emisión. El retardo intencional es una demora corta (generalmente automatizada) que se usa, por ejemplo, para dar tiempo al órgano de difusión de censurar el audio (o vídeo) transmitido, pero no suficiente para permitir trabajos de edición significativos. Si la información es generada completamente por una computadora no es en directo.

(6) Transcripción textual: (en las WCAG se denomina "alternativa para los medios tempodependientes") documento que incluye una secuencia correcta de descripciones textuales de la información visual y auditiva tempodependiente, y que proporciona los medios para lograr los resultados de cualquier interacción basada en el tiempo. El guión empleado para crear el contenido multimedia sincronizado podría satisfacer esta definición sólo si ha sido corregido para representar con precisión el contenido multimedia sincronizado resultante tras la edición.

(7) Alternativa en audio: pista sonora que presenta información equivalente al contenido del medio de sólo vídeo grabado.

(8) Subtítulos: alternativa visual y/o alternativa textual, sincronizada, para la información sonora necesaria para comprender el contenido multimedia, que puede ser tanto hablada como no hablada. Los subtítulos para sordos son similares a los subtítulos que presentan sólo los diálogos, excepto por que los subtítulos para sordos transmiten no sólo el contenido de los diálogos sino también equivalentes para la información sonora que no es diálogo y que es necesaria para comprender el contenido del programa, incluyendo efectos sonoros, música, risas, identificación del hablante y localización.

(9) Audiodescripción: la narración agregada a la pista de sonido para describir los detalles visuales importantes que no se pueden entender sólo con la banda de sonido principal. La audiodescripción del vídeo proporciona información sobre las acciones, personajes, cambios de escena, textos que aparecen en pantalla y otros contenidos visuales. En las audiodescripciones estándares, la narración se añade durante las pausas existentes en el diálogo. Cuando toda la información sobre el vídeo ya se proporciona en el audio de la presentación, no es necesaria ninguna audiodescripción adicional. En inglés también se la denomina "video description" (descripción de vídeo) o "descriptive narration" (narración descriptiva).

(10) Interpretación en lengua de señas: La traducción de un idioma, generalmente un idioma hablado, a lengua de señas. Las lenguas de señas auténticas son idiomas independientes que no están relacionados con las lenguas habladas del mismo país o región.

(11) Audiodescripción ampliada: audiodescripción que se agrega a una presentación audiovisual poniendo en pausa el vídeo, de manera que haya tiempo suficiente para agregar una descripción adicional. Esta técnica se emplea sólo cuando el sentido del vídeo se perdería sin el añadido de una audiodescripción y las pausas entre el diálogo o la narración son demasiado cortas.

Artículo relacionado:

• Reseña: "Accesibilidad a los contenidos audiovisuales en la web"

Para los que han estado desconectados en julio y agosto, estas han sido las dos grandes noticias sobre accesibilidad web del verano:

Actualización de la Norma UNE 139803

El marco legislativo español especifica la obligatoriedad de alcanzar un nivel de conformidad AA de acuerdo a la Norma UNE 139803 a determinadas páginas web. La Norma UNE 139803:2004 estaba basada en las WCAG 1.0

El 4 de julio se publicó su nueva versión, la Norma UNE 139803:2012, que se ha equiparado a las WCAG 2.0

Ampliar información en:

• Nueva versión de la Norma UNE 139803
• Referencia sobre legislación española relacionada con la accesibilidad web

Publicada la ISO 14289-1:2012, más conocida como PDF/UA

Tras muchos años de trabajo se ha publicado el estándar PDF/UA, que recoge las características de la especificación PDF necesarias para la accesibilidad y prohíbe cualquier función permitida por la norma ISO 32000-1:2008 "Document management -- Portable document format-- Part 1: PDF 1.7" que impida la accesibilidad del PDF

Ampliar información en: Publicada la ISO 14289-1:2012, más conocida como PDF/UA

Tal y como comentaba en el artículo "Publicada la ISO 14289-1:2012, más conocida como PDF/UA", el 7 de agosto de 2012 se publicó la norma que define un formato de archivo (PDF/UA) para representar documentos electrónicos PDF de manera que sean accesibles para los usuarios con discapacidad, que marca un hito en la evolución del formato PDF.

Después de una lectura detenida, publico este segundo artículo describiendo el contenido de la norma así como su comparativa y relación con las WCAG 2.0

Descripción de la ISO 14289-1:2012 (PDF/UA)

La ISO 14289-1:2012 Document management applications — Electronic document file format enhancement for accessibility — Part 1: Use of ISO 32000-1 (PDF/UA-1), conocida como PDF/UA, está disponible en inglés y francés, cuesta 86 CHF (unos 71 euros según el cambio) y consta de 24 páginas.

Su propósito es definir un formato de archivo (PDF/UA) para representar documentos electrónicos PDF de manera que sean accesibles para los usuarios con discapacidad. El documento cuenta con una introducción, nueve apartados y una bibliografía.

Los cinco primeros apartados son generales (alcance, normativa de referencia, definiciones, etc.) En el sexto se indica de forma general los requerimientos de conformidad PDF/UA para ficheros PDF, readers y productos de apoyo (como un lector de pantalla). Básicamente y de forma muy simplificada, se dice que deben cumplir con la norma ISO 32000:1:2008 pero de acuerdo a lo especificado en la ISO 14289.

En el apartado 7 se identifican los requisitos para los ficheros PDF, en el apartado 8 para los readers y en el 9 para los productos de apoyo.

En este apartado 7 se remite continuamente a la ISO 32000-1: Document management — Portable document format — Part 1: PDF 1.7 (disponible gratuitamente) por tanto es imprescindible leer ambas normas en paralelo para comprender y aplicar la ISO 14289.

La ISO 32000 tiene 756 páginas, por ello es muy útil que la ISO 14289 pueda servir como un índice para localizar en la ISO 32000 la información relacionada con las características de accesibilidad de los ficheros PDF.

Lo que no vas a encontrar en la ISO 14289-1:2012 (PDF/UA)

La ISO 14289 es una especificación técnica. No te esperes encontrar un manual para hacer PDF accesibles, ni mucho menos un manual para hacer PDF accesibles con Adobe Acrobat.

Por ejemplo, te dirá que se debe espeficar el dc:title y que el DisplayDocTitle debe ser true. Si estás familiarizado con la creación de PDF accesibles comprenderás (pero no te lo va a explicar así) que hace referencia a que el documento debe tener un título y que en las propiedades del documento debes indicar que sea el valor a presentar en el título de la ventana. Y NO te va a decir que en Adobe Acrobat el título se especifica en el menú "Archivo>Propiedades>Descripción [campo título]" y que se indica que sea el valor a mostrar en el título de la ventana en el menú "Archivo>Propiedades>Vista inicial [Mostrar:Título del documento]"

Si lo que necesitas es este tipo de información, hay otros recursos, como luego explicaré.

Tampoco esperes encontrar un manual para cumplir con las WCAG 2.0

Las WCAG 2.0 y la ISO 14289 son en todo caso documentos complementarios, y de hecho, en la norma se remite a veces, para determinados requisitos, a las WCAG 2.0

Comparativa y relación con las WCAG 2.0

Los requisitos de accesibilidad que debe cumplir un PDF para que sea accesible de acuerdo a las WCAG 2.0 pueden ser de dos tipos (es una distinción didáctica que hago yo, no las WCAG 2.0)

Por un lado podríamos hablar de aquellos requisitos de accesibilidad que podemos cumplir modificando directamente el PDF mediante Adobe Acrobat. Por ejemplo, poner el título al documento y que este se visualice en el título de la ventana, indicar el idioma del documento o los cambios de idioma en el contenido, etiquetar de forma semánticamente el documento y con un orden de lectura correcto, incluir texto alternativo a las imágenes o convertir en artefacto las imágenes decorativas, etc.

La forma de cumplir con este tipo de requisitos de accesibilidad se recoge en gran medida en las PDF Techniques for WCAG 2.0 En este documento sí que os van a indicar como aplicarlos en Adobe Acrobat, y no en la ISO 14289 como explicaba antes en relación por ejemplo con el título del documento.

Sin embargo, para que un PDF sea accesible también tiene que cumplir con otro tipo de requisitos de accesibilidad que tienen que ver con su diseño, presentación o contenido. No encontraremos técnicas PDF en las WCAG 2.0 que nos indiquen cómo cumplir con este tipo de requisitos, pues son comunes a otros tipos de documentos, como las páginas HTML, y se aplican técnicas generales.

Este tipo de requisitos de accesibilidad son por ejemplo usar un contraste de color suficiente entre el texto y el color de fondo, no transmitir información sólo con el color o mediante características sensoriales como la forma, el tamaño, la ubicación visual o el sonido, etc. Estos son requisitos que se tienen que tener en cuenta al diseñar la presentación y el contenido del documento y que no vamos a poder modificar a posteriori en el PDF mediante Adobe Acrobat.

El objetivo de la ISO 14289 es definir un estándar técnico que proporcione un medio coherente para lograr la accesibilidad mediante la tecnología PDF, que el software de creación y procesamiento de archivos PDF pueda generar ficheros conformes que sean interpretados de forma consistente por los lectores de PDF y los productos de apoyo.

El objetivo por tanto de la ISO 14289 es diferente al de las WCAG 2.0, y en ningún caso es crear documentos conformes con las mismas. Por ello, cuando podamos guardar un fichero PDF/UA conforme, tendrá muchas características de accesibilidad (tendrá un título, tendrá especificado el idioma, estará etiquetado, las imágenes tendrán texto alternativo, etc.) que podrán ser interpretadas correctamente y de forma consistente por los readers PDF y los productos de apoyo. Pero nunca podrá asegurarse que es conforme a las WCAG 2.0 per se, solo por ser PDF/UA conforme, pues podrá ser que el texto alternativo de las imágenes no sea adecuado, o que los textos no tengan suficiente contraste de color con el fondo, etc.

En Achieving WCAG 2.0 with PDF/UA de AIIM encontrarás los requisitos de más que tienes en las WCAG 2.0 y los requisitos PDF/UA que no están en las WCAG 2.0 Pero sobre todo te será de utilidad la tabla de equivalencia entre los criterios de conformidad de las WCAG 2.0 y los apartados de la ISO 14289 y la ISO 32000

¿Y si no puedo comprar la ISO 14289 qué recursos puedo consultar?

Las WCAG 2.0, la ISO 32000 son gratuitas, así como otros recursos. Si tu trabajo es convertir PDF en PDF accesibles o validar que los PDF son accesibles, si no puedes o no quieres gastarte los 71 euros que vale la ISO 14289, creo que puedes suplir su lectura con estos documentos:

• Lo primero es conocer las WCAG 2.0 y las PDF Techniques for WCAG 2.0
• En el documento de la WAI Accessibility Support Documentation for PDF tienes una tabla de aplicación de los criterios de conformidad de las WCAG 2.0 a los ficheros PDF, donde se hace referencia a las técnicas PDF o a los apartados de la ISO 32000 relacionados.
• En Achieving WCAG 2.0 with PDF/UA de AIIM ya he comentado que encontrarás los requisitos de más que tienes en las WCAG 2.0, los requisitos PDF/UA que no están en las WCAG 2.0, y la tabla de equivalencia entre los criterios de conformidad de las WCAG 2.0 y los apartados de la ISO 14289 y la ISO 32000
• También son muy útiles las Acrobat X accessibility guides

Artículos relacionados:

• Publicada la ISO 14289-1:2012, más conocida como PDF/UA
• PDF Techniques for WCAG 2.0
• PDF accesibles
• PDF accesibles (2): metodología
• ePub accesibles

Servicios relacionados

• Curso "Creacción de PDF accesibles"
• Conversión de PDF en PDF accesibles"

Hace unos meses os recomendaba en el artículo "HTML 5 y accesibilidad" el trabajo fin de carrera de Alberto Sánchez-Heredero Pérez, tutorizado por Lourdes Moreno López ⁽¹⁾, "Accesibilidad a los contenidos audiovisuales en la Web a través de HTML5" (PDF, 2MB)

Ya entonces me pareció un trabajo muy bueno. Hoy me ha informado Alberto de que su proyecto ha sido el ganador del premio Fundación Universia-Fundación Vodafone España por favorecer la accesibilidad en el ámbito de las Tecnologías de la Información y la Comunicación (TIC).

Enhorabuena!

Ya está disponible la nueva versión de Acrobat: "Adobe Acrobat XI Pro", que trae novedades respecto al tratamiento de la accesibilidad en los documentos PDF, entre ellas:

• Han mejorado el asistente para hacer PDF accesibles que incluyeron en la versión X Pro. Ahora el asistente permite acciones que en la versión X no se podían hacer desde el asistente: especificar el idioma del documento o incluir el texto alternativo de las imágenes. En cualquier caso, el asistente no puede sustituir el trabajo manual que hay que hacer.
• Se ha mejorado el validador de accesibilidad, que ahora permite la validación de acuerdo a las WCAG 2.0 y la ISO 14289-1:2012 (PDF/UA)
• Se ha simplificado la forma de insertar texto alternativo para las imágenes.

En cuanto pruebe la nueva versión os comento más cosas.

Podéis ampliar información en la web de Acrobat.

Artículos relacionados:

• PDF/UA. Descripción de la norma. Comparativa y relación con las WCAG 2.0
• PDF accesibles
• PDF accesibles (2): metodología
• ePub accesibles
• PDF Techniques for WCAG 2.0

Servicios relacionados:

• Conversión de PDF en PDF accesibles
• Curso "Creacción de PDF accesibles"