LA INFORMACIÓN Y EL MANEJO DE LA INTERFAZ DE USUARIO DEBEN SER COMPRENSIBLES.

El objetivo de este principio es que la información y la forma de operar los elementos de interfaz de usuario sean comprensibles. Es decir, el contenido del sitio web y la forma de interactuar con él no pueden ir más allá de la capacidad de entendimiento de los usuarios.

Este principio está formado por tres pautas:

PAUTA 3.1 LEGIBLE

Hacer que los contenidos textuales resulten legibles y comprensibles.

La finalidad principal de esta pauta es asegurar que la información necesaria para comprender el documento está disponible y que el contenido textual es legible y comprensible para los usuarios y productos de apoyo.

La aplicación de esta pauta mejora la capacidad para entender el contenido por parte de personas con discapacidad y, en general, por parte de cualquier usuario de productos de apoyo.

PAUTA 3.2 PREDECIBLE

Hacer que las páginas web aparezcan y operen de manera predecible.

El objetivo de esta pauta es presentar el contenido de forma predecible entre las diferentes páginas del sitio web, así como hacer que el comportamiento de los componentes interactivos y funcionales sea también predecible.

El presentar el contenido y la funcionalidad de forma predecible es debido a que los usuarios con discapacidad tienen dificultades añadidas para la comprensión de las páginas web. Por ejemplo:

• Los lectores de pantalla leen contenido de forma secuencial lo que dificulta la comprensión de las relaciones espaciales.
• Los usuarios de magnificadores de pantalla sólo perciben parte del contenido, perdiendo la información de contexto y los cambios producidos en el resto del contenido fuera del área de visión.
• Las personas con problemas cognitivos sufren desorientación cuando la navegación no tiene un comportamiento predecible.

PAUTA 3.3 ENTRADA DE DATOS ASISTIDA

Ayudar a los usuarios a evitar y corregir los errores.

El objetivo es reducir el número de errores importantes o irreversibles que se pueden producir al interactuar con el sitio web e informar y ayudar a los usuarios a corregir los errores en caso de que se produzcan.

Si bien nadie está libre de cometer algún error a la hora de interactuar con un sitio web o al introducir datos en un formulario, las personas con discapacidad son más propensas a cometer errores y encuentran más dificultades para detectarlos y corregirlos.

Por otra parte, los mecanismos empleados habitualmente para informar sobre los errores producidos no suelen ser obvios para las personas con discapacidad (campo de visión reducido, problemas en la percepción de colores, uso de lectores de pantalla y otras ayudas técnicas que acceden al documento de forma secuencial, etc.).

En esta pauta de trata de evitar que los usuarios cometan errores y, en caso de que se produzcan, informar adecuadamente y ayudar a corregirlos.

Hacer que los contenidos textuales resulten legibles y comprensibles

La finalidad principal de esta pauta es:

• Asegurar que la información necesaria para comprender el documento está disponible.
• Permitir que el contenido textual sea legible y comprensible para los usuarios y productos de apoyo.

La aplicación de esta pauta mejora la capacidad para entender el contenido por parte de personas con discapacidad y, en general, por parte de cualquier usuario de productos de apoyo.

• Las personas con discapacidades cognitivas o problemas de lectura pueden encontrar dificultades para comprender textos redactados con lenguaje complejo, palabras inusuales, ambiguas y abreviaturas.
• Las personas cuya lengua materna es diferente de la usada en el documento pueden tener problemas similares.
• Las personas con sordera prelocutiva (sordera ocurrida antes de aprender a hablar) tienen dificultades para comprender el texto escrito
• Los lectores de pantalla necesitan saber el idioma usado para usar la pronunciación adecuada, así como la dirección de lectura del texto (de izquierda a derecha, de derecha a izquierda, etc.)
• Etc.

Estas dificultades, menores para la mayoría de los usuarios, son más importantes para las personas con discapacidad.

El idioma predeterminado de cada página web puede ser determinado por software.

Objetivo:

Proporcionar la información necesaria para que los agentes de usuarios puedan presentar el texto y otro contenido lingüístico de forma correcta.

Los lectores de pantalla que reproducen varios idiomas tienen la capacidad de usar el acento y la pronunciación adecuados para cada idioma. Identificar el idioma principal usado en la página evita que estos productos de apoyo intenten pronunciar el texto en el idioma por defecto de éstas herramientas. Si un texto se lee con una pronunciación que no se corresponde con el idioma usado es posible que dicho texto resulte incomprensible.

De igual forma, los agentes de usuario y navegadores gráficos pueden mostrar los caracteres y sistema de escritura (alfabeto, signos de puntuación, etc.) de forma correcta según el idioma. Asimismo, los reproductores multimedia podrían mostrar los subtítulos adecuados según el idioma principal del documento.

Beneficiarios:

Beneficia especialmente a usuarios de lectores de pantalla y productos de apoyo similares (personas con discapacidades visuales, dificultades de lectura o con problemas cognitivos o de aprendizaje que usen lectores de pantalla).

¿CÓMO CUMPLIR?

Identificar el idioma del documento mediante el uso de los atributos lang y/o xml:lang

Para que los lectores de pantalla sean capaces de reconocer el idioma empleado es necesario identificar el idioma principal de la página mediante los atributos lang y/o xml:lang usados según las siguientes reglas: * En HTML debemos usar el atributo lang y un código de idioma.

Ejemplo:

<center>1. <html lang="es">    </center>

En XHTML 1.0 servido como text/html debemos usar xml:lang junto con lang.

<center>1. <html xmlns="http://www.w3.org/1999/xhtml" lang="es" xml:lang="es"> </center>

En XTHML 1.0 y 1.1 servido como XML usaremos únicamente el atributo xml:lang.

<center>1. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es"></center>

Para la identificación de los diferentes idiomas seguiremos los códigos del Registro de etiquetas de idioma del IANA.

Para saber qué código de idioma usar podemos consultar el listado de códigos de idioma de IANA ([http://www.iana.org/assignments/language-subtag-registry http://www.iana.org/assignments/language-subtag-registry]).

A continuación se indican como ejemplo los códigos para algunos de los idiomas más usuales:

• Español: es
• Inglés: en
• Francés: fr
• Alemán: de
• Italiano: it
• Ruso: ru

Cuando un documento posee más de un idioma, seguiremos los siguientes criterios para establecer cuál es el idioma principal:

• Si todos los idiomas están en la misma proporción, se identificará como idioma principal el que primero se encuentre en el documento.
Si no están en la misma proporción, se identificará como principal el del grueso del contenido o el que más frecuencia presente.

El idioma de cada pasaje o frase en el contenido puede ser determinado por software, excepto los nombres propios, términos técnicos, palabras en un idioma indeterminado y palabras o frases que se hayan convertido en parte natural del texto que las rodea.

Objetivo:

Asegurar que los agentes de usuario y productos de apoyo presentan correctamente el contenido en múltiples idiomas.

Identificar los cambios de idioma que se producen en los contenidos evita que los lectores de pantalla intenten pronunciar el texto en el idioma principal usado en el documento o en el idioma por defecto de éstas herramientas. Si un texto se lee con una pronunciación que no se corresponde con el idioma usado es posible que dicho texto resulte incomprensible.

Beneficiarios:

Beneficia especialmente a usuarios de lectores de pantalla y productos de apoyo similares (personas con discapacidades visuales, dificultades de lectura o con problemas cognitivos o de aprendizaje que usen lectores de pantalla).

¿CÓMO CUMPLIR?

Identificar los cambios de idioma respecto al principal mediante el uso de los atributos lang y/o xml:lang

Si se emplean varios idiomas en una página, debemos identificar los cambios de idioma con el código correspondiente.

Para marcar el idioma de un texto en (X)HTML hay que usar los atributos lang y/o xml:lang según las mismas reglas vistas para identificar el idioma principal. Estos atributos se pueden aplicar a todos los elementos excepto

<applet>, <base>, <basefont>, <br>, <frame>, <frameset>, <iframe>, <param> y <script>.

EJEMPLO:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "<u>http://www.w3.org/TR/html4/strict.dtd</u>"> 
<html lang="es"> 
<head> 
<meta http-equiv="content-type" content="text/html"; charset="utf-8" /> 
... 
<ul> 
   <li><a lang="en" href="index.aspx?lang=en">English</a></li> 
   <li><a lang="fr" href="index.aspx?lang=fr">Français</a></li> 
   <li><a lang="de" href="index.aspx?lang=de">Deutsch</a></li> 
   <li><a lang="ru" href="index.aspx?lang=ru">Русский</a></li> 
</ul>

No es necesario que marquemos todas y cada una de las palabras que estén en un idioma diferente. Se consideran las siguientes excepciones:

• Como norma general, los términos sueltos no se consideran como un cambio de idioma a no ser que esté claro que se pretendía un cambio de idioma.
• Si hay dudas sobre si se pretendía un cambio de idioma o no, comprobar que su pronunciación sea similar (excepto el acento o la entonación) en el idioma principal.

Por tanto, podrían considerarse excepciones (dependiendo del caso concreto) los nombres propios, términos técnicos y títulos o términos de uso común (adoptados en el idioma) con pronunciación similar en el idioma principal del documento (generalmente anglicismos). Por ejemplo: broker, mailing, catering, chat, password, copyright, rating, diskette, establishment, jet-lag, fast-food, hit, link, office, living, showman, single, software, stop, suite, thriller, topless, e-mail, zapping, etc...

Se proporciona un mecanismo para identificar las definiciones específicas de palabras o frases usadas de modo inusual o restringido, incluyendo expresiones idiomáticas y jerga.

Objetivo:

Favorecer la comprensión del documento a personas con dificultad para entender el uso de palabras de forma no literal, usos o palabras especializadas, el lenguaje figurado u otros usos especializados.

Se considera que una palabra o término se usa de forma inusual cuando:

• Existen varias definiciones posibles pero sólo una es válida para comprender el contenido.
• La definición necesaria para comprender el contenido se considera como "rara", "arcaica" u "obsoleta".
• El autor usa alguna palabra o término asignándole un nuevo significado (diferente, más restrictivo, más amplio, etc.). Por ejemplo, la palabra "Tecnología" en las WCAG se emplea de forma más restrictiva que el término general ("Mecanismo para codificar instrucciones para ser mostradas, reproducidas o ejecutadas por los agentes de usuario, incluyendo lenguajes de marcado, formatos de datos y lenguajes de programación usados pasa producir y transmitir contenido web").

También se consideran palabras poco usuales:

• Jergas y argot: vocabulario especializado de una profesión, campo técnico o grupo social (Por ejemplo: driver, controlador, acceso directo, ancho de banda, fifo, gusano, virus, troyano, kernel, lan, servidor, slot).
• Dialectos y expresiones: lenguaje usado comúnmente en determinadas regiones pero no en otras zonas geográficas donde se usa el mismo idioma (Por ejemplo: lana=dinero, guagua=camión, güaje=niño, manque=aunque, antroxu=carnaval) .
• Extranjerismos: palabras poco usuales adoptadas de otro idioma (Por ejemplo: broadcasting, fair play, full time, handicap, speaker, staff).
• Dichos y frases hechas: frases cuyo significado no surge directamente del significado de las palabras, y estas no se pueden cambiar sin perder el significado. No se pueden traducir directamente, palabra a palabra.

Por ejemplo, "A bote pronto", "A buenas horas mangas verdes", "Armar la de San Quintín", "Borrón y cuenta nueva", "Arrimar el ascua a su sardina", "Cerrar a cal y canto", "Caer del guindo" Etc.

A pesar de ser un criterio de conformidad de nivel AAA, se recomienda también su aplicación incluso para niveles A o AA si se va a proporcionar información especializada (legal, médica, técnica) para un público no especializado (público en general).

Beneficiarios:

Beneficia especialmente a personas con discapacidades cognitivas, de lenguaje y aprendizaje (también a personas que usan magnificadores de pantalla y pierden el contexto del contenido).

¿CÓMO CUMPLIR?

Si la palabra o frase tiene un SIGNIFICADO ÚNICO en la página web, proporcionar la definición la PRIMERA VEZ que aparezca .

Cuando la palabra o frase que se usa de forma inusual tiene un significado único en la página web se considera que es suficiente proporcionar su definición la primera vez que aparece en la página.

Para proporcionar la definición de las palabras inusuales tenemos básicamente las siguientes opciones:

• Usar un enlace a la definición.
• Proporcionar la definición en línea, en el propio texto de la página.
• Crear un glosario con las definiciones.
• Dar acceso a una función de búsqueda en un diccionario online.

Enlace a la definición.

La forma más efectiva de proporcionar las definiciones es enlazándolas. El enlace permite establecer una relación directa entre el término y la definición. De esta forma se permite consultar la definición siguiendo el enlace y volver al contenido (botón atrás) una vez finalizada la consulta.

La definición puede proporcionarse en la misma página (por ejemplo, al final de la misma) mediante un enlace interno o en una página aparte enlazada. Por ejemplo, se puede usar un glosario donde se incluyan todas las definiciones de la página o del sitio.

A la hora de proporcionar la definición podemos usar listas de definición y para enlazar a la misma usar el elemento <link> si existe un glosario.

Listas de definición

Tal y como ya vimos en el criterio de conformidad 1.3.1, con las listas de definición (<dl>) podemos proporcionar definiciones para diferentes palabras y términos. A diferencia de los otros tipos de listas, constan de dos partes: término (<dt>) y definición (<dd>).

Elemento <link> para enlazar el glosario

Si en el sitio web se está usando una página a modo de glosario, donde se incluyen las definiciones de las palabras, términos o frases raras e inusuales, entonces podemos usar el elemento <link> para enlazar con el glosario.

El elemento <link> sirve principalmente para enlazar entre sí una colección de documentos relacionados.

Mediante el atributo rel se indica el tipo de vínculo existente entre los documentos. Es decir, cuál es la relación que existe entre ambos documentos. Así, podemos establecer una relación entre la página actual y la que contiene el glosario.

Los diferentes valores para se pueden usar para el atributo rel son:

Start: primer documento en una colección de documentos.

Next: siguiente documento en una colección secuencial de documentos. Los agentes de usuario pueden precargar el siguiente documento para reducir los tiempos de carga.

Prev: documento anterior en una colección.

Contents: la tabla de contenidos.

Index: índice del documento actual.

Glossary: glosario de términos relacionados con el documento actual.

Chapter: capítulo en una colección de documentos.

Section: sección en una colección de documentos.

Subsection: subsección de una colección de documentos.

Appendix: apéndice de una colección de documentos.

Help: documento con ayuda sobre la navegación, contacto, otros enlaces, etc.

Así, para indicar cuál es la página con el glosario usaremos el elemento <link> con el atributo rel="glossary".

Ejemplo:

<head> 
   <title>Título del documento</title>
   <link rel="glossary" href="glosario.html"> 
</head>

PROPORCIONANDO DEFINICIONES EN LÍNEA

Se trata, básicamente, de incluir la definición directamente en el texto, justo antes o después del término a definir.

Por ejemplo, entre paréntesis o en una frase a continuación.

Además, podemos indicar que un término tiene una definición asociada si lo marcamos con el elemento <dfn>.

Elemento <dfn> para identificar el término

Con este elemento identificamos el término definido, no la definición.

Ejemplo:

<p> ... <dfn>término</dfn> (definición) ... </p> 

Glosario

El uso de un glosario es más adecuado cuando todos los términos están relacionados. Por ejemplo, cuando todos los términos pertenecen a una misma disciplina. En el glosario, además de indicar la definición, también se puede incluir la pronunciación de las palabras.

El glosario se puede incluir en la misma página, al final de la misma, o bien en otra página aparte enlazada. Si el glosario está en una página aparte podemos enlazarla de diversas formas:

• Enlace al glosario en una sección de utilidades.
• Elemento <link>, como se explicó antes al tratar los enlaces a las definiciones.

Es importante tener en cuenta que el glosario sólo puede contener una definición por cada término. En caso contrario, si existen varias definiciones para un mismo término entonces un glosario no es suficiente para cumplir este criterio de conformidad.

Esto se debe a que en ese caso no es posible saber cuál es la definición adecuada para el término. De igual forma, y por el mismo motivo, un glosario tampoco es suficiente cuando el término se usa con diferentes significados dentro de la página web.

En ambos casos sólo podemos usar un glosario si además usamos alguna técnica que permita relacionar inequívocamente el término con la definición correcta. Por ejemplo, usando un enlace directo entre el término y la definición correspondiente.

Función de búsqueda en un diccionario online

Incluir una función de búsqueda en un diccionario online evita que tengamos que crear un glosario propio o incluir las definiciones. Sin embargo, sólo podemos usar una función de búsqueda si nos aseguramos que el diccionario online devuelve la definición correcta para el término empleado.

No podemos emplear una función de búsqueda en un diccionario online cuando el término o palabra inusual se usa con diferentes significados en la página. En este caso, la función de búsqueda no podrá devolver el significado adecuado para cada aparición del término.

Si la palabra o frase tiene VARIOS SIGNIFICADOS en la página web, proporcionar la definición CADA VEZ que aparezca .

Cuando la palabra o frase tiene varios significados en la misma página web, debemos proporcionar la definición cada vez que aparezca. Es la única forma de proporcionar la definición correcta para cada caso.

Para proporcionar las definiciones podemos usar algunas de las técnicas que vimos antes, sólo que ahora es necesario que la definición se de para cada ocurrencia de la palabra o frase inusual, y no sólo la primera vez. Para ello podemos:

• Usar un enlace a la definición.
• Proporcionar la definición en línea, en el propio texto de la página.

Como vimos antes, si el término tiene varios significados en la página web no es suficiente usar un glosario con varias definiciones para cada término porque no es posible saber cuál es la definición adecuada. Únicamente podemos usar un glosario si además enlazamos cada aparición del término con la definición correcta, para relacionar inequívocamente cada término con su definición.

Por el mismo motivo, cuando el término tiene varios significados, no podemos usar una función de búsqueda en un diccionario online porque no podemos asegurar que devuelva el significado adecuado para cada aparición del término.

Se proporciona un mecanismo para identificar la forma expandida o el significado de las abreviaturas.

Objetivo:

Asegurarnos que los usuarios pueden conocer la expansión de las formas abreviadas

Podemos diferenciar varios tipos de formas abreviadas:

Abreviaturas: Representación reducida de una palabra mediante la supresión de letras finales o centrales y que suele finalizar con un punto. Se leen traduciendo a la forma expandida. Ejemplos: Sr. (señor), Av. (avenida), Dcha. (derecha), Fdo. (firmado), Dr. (doctor), D. (don).

Siglas: Palabra formada por las letras de varios términos, generalmente las iniciales. Se leen tal como está escritas, deletreando o como una palabra. Ejemplos: W3C, BOE, ISBN, ONG.

Acrónimos: Siglas que se leen como palabras o "vocablos" formados por parte de dos o más palabras, generalmente por el inicio de la primera y el final de la última. Siempre se escriben y leen como una palabra normal. Ejemplos: modem (modulación-demodulación), telemática (telecomunicación informática), pyme (pequeña y mediana empresa), sida (síndrome de inmunodeficiencia adquirida), ovni (objeto volador no identificado), láser (Light Amplification by Stimulated Emission of Radiation, Amplificación de Luz por Emisión Estimulada de Radiación).

Las abreviaturas presentan una serie de problemas (aparte del desconocimiento de su significado) que pueden suponer una barrera adicional a las personas con discapacidad.

Su pronunciación no suele transmitir significado.

La misma abreviatura puede tener diferentes significados según el contexto. Por ejemplo, la abreviatura "Dr." en inglés significa tanto "Doctor" como "Drive" (calle). También la abreviatura "CSS" se puede referir a "Cascading Style Sheets" como a "Commonwealth Superannuation Scheme" o "Content Scrambre System".

Pueden ser iguales a palabras ya existentes. Por ejemplo "JAWS", nombre del lector de pantalla y abreviatura de "Job Access with Speech", en inglés significa mandíbulas.

Pueden tener la misma pronunciación que palabras existentes. Por ejemplo "SMIL", abreviatura de "Synchronized Multimedia Integration Language" en inglés se pronuncia igual que "smile" (sonrisa).

Beneficiarios:

Beneficia especialmente a personas con discapacidades cognitivas, de lenguaje y memoria (también a personas que usan magnificadores de pantalla y pierden el contexto del contenido).

¿CÓMO CUMPLIR?

Si la abreviatura tiene un SIGNIFICADO ÚNICO en la página web, proporcionar la expansión o explicación la PRIMERA VEZ que aparezca .

Al igual que ocurre al proporcionar definiciones para términos inusuales, en el caso de las abreviaturas que tienen un único significado en la página también debemos proporcionar la expansión o explicación de la misma la primera vez que aparezca en la página.

En ocasiones es más apropiada una explicación que la expansión literal de la abreviatura. Por ejemplo, las abreviaturas a.m. y p.m. es mejor explicar su significado ("por la mañana" y "por la tarde", respectivamente) que dar la expansión literal, la cual puede no ser entendida por todos los usuarios ("Ante merídiem" y "Post merídiem", respectivamente)

Existen algunas excepciones en las que no es necesario proporcionar la explicación o expansión:

• Lexicalización: formas abreviadas que han pasado a formar parte del lenguaje. Por ejemplo: cedé, radar, sida.
• Siglas usadas como nombres de empresas, entidades, etc., que se mencionan como nombre propio sin la intención de transmitir el significado de la expansión. Por ejemplo: UAESPE

Para proporcionar las expansiones o explicaciones de las formas abreviadas tenemos las siguientes opciones:

• En el texto, antes de la forma abreviada : Una forma rápida y efectiva es proporcionar la expansión en el texto, antes de la forma abreviada. Por ejemplo, se puede poner la expansión y, entre paréntesis, la forma abreviada. En el caso de que en vez de la expansión lo que queramos dar sea una explicación o definición, es mejor usar otra técnica, como enlazar a las definiciones.
• Enlazando a las definiciones : Al igual que ocurría con las palabras inusuales, se puede proporcionar la expansión o explicación de la forma abreviada mediante un enlace. La expansión puede proporcionarse en la misma página (por ejemplo, al final de la misma) mediante un enlace interno o en una página aparte enlazada.
• Mediante los elementos <abbr> y <acronym> : Para identificar las abreviaturas y acrónimos se pueden emplear los elementos <abbr> y <acronym> respectivamente. La expansión de las mismas se proporciona en el atributo title de dichos elementos.

Ejemplo:

En la UAESPE se trabaja por la integración de los trabajadores colombianos con discapacidad, al aplicar las pautas de accesibilidad del W3C en su Pag. web

<p>En la
<acronym title="Unidad Administrativa Especial del Servicio 
Público de Empleo">UAESPE </acronym> se trabaja por la
integración de los trabajadores colombianos con discapacidad, 
al aplicar las pautas de accesibilidad del 
<acronym title="World Wide Web Consortium" xml:lang="en"> 
W3C </acronym> en su <abbr title="Página"> 
Pag. </abbr> web.
</p>

Aunque existan dos elementos que diferencian entre abreviaturas y acrónimos, en la práctica se permite usar <abbr> para todo tipo de formas abreviadas, tanto abreviaturas, como siglas y acrónimos.

Precisamente, debido a la dificultad de diferenciar entre abreviaturas, siglas y acrónimos, en XHTML 2.0 se propone eliminar el elemento <acronym> y dejar sólo el elemento más general <abbr>

Otros ejemplos de acrónimo:

• Unasur, Unión de Naciones Suramericanas.
• emoticono, emotícono o emoticón, del inglés emoticon = emotion + icon, ‘emoción’ e ‘icono’. Traducción incompleta de otro acrónimo inglés.
• informática de ‘información automática’ = infor + mática
• ofimática, de oficina e informática.
• TIC, Tecnologías de Información y las Comunicaciones.
• led, del inglés Light Emitting Diode (‘diodo emisor de luz’).

Glosario.

Al igual que en el caso de las palabras o frases inusuales, podemos usar un glosario para proporcionar la expansión o explicación de las formas abreviadas que aparecen en la página web.

Función de búsqueda en un diccionario online .

Incluir una función de búsqueda en un diccionario online evita que tengamos que crear un glosario propio o incluir directamente las expansiones o explicaciones de las formas abreviadas. Sin embargo, sólo podemos usar una función de búsqueda si nos aseguramos que el diccionario devuelve la expansión o explicación correcta para la forma abreviada usada.

SI LA ABREVIATURA TIENE VARIOS SIGNIFICADOS EN LA PÁGINA WEB, PROPORCIONAR LA EXPANSIÓN O EXPLICACIÓN CADA VEZ QUE APAREZCA

Cuando la forma abreviada tiene varios significados en la misma página web, debemos proporcionar la expansión o explicación cada vez que aparezca. Es la única forma de proporcionar la expansión o explicación correcta para cada caso.

Para proporcionar las expansiones o explicaciones podemos usar algunas de las técnicas que vimos antes, sólo que ahora es necesario que se haga para cada ocurrencia de forma abreviada, y no sólo la primera vez. Para ello podemos

• Usar un enlace a la definición.
• Proporcionar la expansión usando los elementos <abbr> o <acronym>

Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo.

Objetivo:

Asegurar que existe contenido adicional para comprender textos complejos y difíciles.

Establecer una medida comprobable para saber cuándo es necesario ese contenido adicional.

Al hablar de legibilidad se establece como medio de comparación el nivel de educación necesario para leer el contenido textual.

Beneficiarios:

Beneficia especialmente a personas con problemas para comprender e interpretar el lenguaje escrito. Como pueden ser personas con sordera prelocutiva (adquirida antes de aprender a hablar), discapacidades cognitivas, dislexia, etc.

¿COMO CUMPLIR?

ILUSTRACIONES O IMÁGENES QUE AYUDEN A EXPLICAR IDEAS, PROCESOS, ETC.

Es común encontrarse que la versión accesible de algunos portales web se trata de versiones sólo de texto. Esta práctica lo que hace es eliminar una fuente de posibles problemas de accesibilidad, pero no es la solución correcta.

La solución pasa por hacer las imágenes accesibles, no por eliminarlas.

Los elementos gráficos se deben usar, siempre que sea posible, como complemento y apoyo del texto para facilitar su comprensión. Las imágenes deben ser fáciles de entender y tener una clara vinculación con el texto.

Las imágenes complementarias aportan las siguientes ventajas:

• Transmiten información a las personas que no pueden leer o tienen dificultades de lectura.
• Sirven de ayuda a las personas con sordera, en especial con sordera prelocutiva, que suelen tener problemas con la comprensión del lenguaje escrito y están más familiarizados con el lenguaje de signos.
• Permiten la comprensión de los documentos a personas con problemas cognitivos o con limitaciones en su formación, que se puedan ver superadas por la complejidad de la información proporcionada en el texto.
• Potencian la capacidad de comprensión de los usuarios en general.

Las ilustraciones no se pueden considerar únicamente como un aspecto decorativo sino como un medio de transmitir información.

• La fotografía de una persona es un complemento ideal al nombre de la misma, ya que es posible que algunos usuarios no la reconozcan por el nombre pero sí por la fotografía.
• La fotografía de un lugar conocido puede ser más informativa que una dirección escrita y servir de complemento para reconocer el lugar.
• En documentos complejos las fotografías pueden ser útiles para ilustrar objetos, aparatos tecnológicos, lugares, etc.
• En muchas ocasiones, un dibujo o una ilustración puede ser la mejor solución. Un dibujo claro y sencillo, centrado en el tema principal, transmite una información más precisa que una fotografía con demasiados detalles o con poca calidad de imagen.
• Los conceptos complejos y/o abstractos se pueden explicar más fácilmente con el apoyo de ilustraciones o esquemas.

Tanto las fotografías como las ilustraciones o dibujos han de ser claros y hacer clara referencia al tema del texto.

Asimismo, tal y como se comenta en el capítulo sobre imágenes, todos los elementos gráficos deben de adoptar las medidas de accesibilidad necesarias. Por ejemplo, un adecuado texto alternativo o una descripción larga, así como un contraste suficiente que permita percibirlas sin dificultad.

RESUMEN DEL TEXTO DE FORMA QUE REQUIERA UN NIVEL DE LECTURA MENOR

En el caso de que el texto requiera un nivel de educación superior al requerido por este criterio de conformidad podemos proporcionar un resumen breve, con la información e ideas más importantes, redactado de forma clara y sencilla que requiera un nivel de lectura menor. El resumen debe proporcionarse de forma adicional al contenido original, en la misma página o en una página aparte enlazada.

HACER EL TEXTO MÁS FÁCIL DE LEER

Un documento de fácil lectura contiene sólo la información más importante expresada de la forma más directa (las ideas, palabras y frases innecesarias deben eliminarse o evitarse en la medida de lo posible) de forma que pueda ser comprendido por el mayor número de personas.

Aunque depende del tipo de público al que se destina el documento, para elaborar un texto que sea comprensible y, por tanto, accesible para el mayor número de personas existen algunas recomendaciones generales.

• Limitar los párrafos a una única idea principal.
• Utilizar oraciones cortas y con una estructura sencilla (sujeto, verbo, predicado).
• Dividir las frases largas en dos.
• Evitar frases con más de dos conjunciones y subordinadas.
• Emplear palabras sencillas y relativas al lenguaje cotidiano.
• Evitar el uso de jergas.
• No emplear palabras en otro idioma.
• Eliminar palabras redundantes que no afectan al significado.
• Usar verbos precisos para describir acciones.
• Usar preferiblemente la voz activa a la pasiva.
• No emplear el subjuntivo.

VERSIÓN HABLADA DEL TEXTO

La versión hablada del texto resulta útil a personas que tienen dificultad para comprender textos escritos.

Según el tipo de contenido podemos diferenciar entre:

• Contenido estático: si el contenido es estático se puede proporcionar una lectura en voz del texto o bien una sintetización automática. Al archivo de audio debe estar en un formato ampliamente soportado y en el enlace al archivo se debe indicar dicho formato.
• Contenido dinámico: en caso que el contenido sea dinámico se puede emplear un método de servidor para proporcionar la versión hablada. Por ejemplo, un botón para iniciar la conversión automática del texto a voz.

VERSIONES EN LENGUA DE SEÑAS DE LA INFORMACIÓN, IDEAS Y PROCESOS QUE DEBAN SER ENTENDIDOS PARA USAR EL CONTENIDO

La lengua de señas es la lengua principal para las personas con sordera prelocutiva al haber perdido la audición antes de aprender a hablar o a leer el texto escrito.

El intérprete de lenguaje de señas se ha de proporcionar de forma adicional al texto. No es necesario que transcriba todo el contenido, pero sí el contenido con cierta complejidad, como la descripción de conceptos complejos o procesos.

La versión en lengua de señas se puede proporcionar en un video contenido en la misma página o bien enlazado en otra página.

Se proporciona un mecanismo para identificar la pronunciación específica de las palabras cuando el significado de esas palabras, dentro del contexto, resulta ambiguo si no se conoce su pronunciación.

En algunos idiomas existen palabras idénticas pero que, según su significado, tienen diferente pronunciación. Por ejemplo, en inglés la palabra "desert" tiene diferente pronunciación dependiendo si se usa con el significado de "abandonado" o con el de "región árida".

Si el significado se intuye por el contexto no hace falta indicar la pronunciación. En caso contrario, sí.

Beneficiarios:

Beneficia especialmente a usuarios de lectores de pantalla y productos de apoyo similares o que tengan problemas de lectura o comprensión

¿CÓMO CUMPLIR?

INDICAR LA PRONUNCIACIÓN TRAS LA PALABRA

Se puede indicar la pronunciación entre paréntesis después de la palabra.

Si la palabra se usa con un único significado en la página web entonces es suficiente con indicar la pronunciación la primera vez que aparezca en el documento. Si, por el contrario, en la misma página existen palabras iguales con pronunciaciones diferentes, esta técnica no es suficiente a no ser que se haga para cada ocurrencia de la palabra.

ENLAZAR A LAS PRONUNCIACIONES

La pronunciación de una palabra también se puede proporcionar mediante un enlace a su pronunciación, la cual puede estar en la misma página o en una página aparte. Por ejemplo, se puede enlazar a un diccionario online que contenga la pronunciación o a un archivo de audio con la pronunciación.

Si la palabra se usa con un único significado en la página web entonces es suficiente con enlazar a la pronunciación la primera vez que aparezca en el documento. Si, por el contrario, en la misma página existen palabras iguales con pronunciaciones diferentes, habría que enlazar todas las ocurrencias de la palabra.

GLOSARIO

Para que un glosario se considere suficiente para cumplir este criterio de conformidad debe incluir información sobre la pronunciación de aquellas palabras cuyo significado dependa de la misma.

INDICAR LA PRONUNCIACIÓN USANDO UNA TÉCNICA ESPECÍFICA DE LAS SIGUIENTES

Elemento <ruby> (XHTML 1.1)

El elemento <ruby>, perteneciente a XHTML 1.1, se usa para indicar la pronunciación de palabras. Es útil principalmente en japonés y otros idiomas asiáticos. En idiomas que usan marcas diacríticas para indicar la pronunciación no es necesario. Tampoco es común su uso en inglés y otros idiomas europeos.

En un conjunto ruby se usa el elemento <rb> (ruby base) para indicar el texto original; el elemento <rt> (ruby text) para indicar la pronunciación; y el elemento <rp> (ruby paréntesis) para indicar entre paréntesis la pronunciación para aquellos agentes de usuario que no soporten el elemento <ruby> (si el agente de usuario sí lo soporta entonces no se muestra el paréntesis ni su contenido).

Ejemplo:

<p>Estas pautas, conocidas como  
   <ruby>
      <rb>WCAG</rb>
      <rp>(</rp>
            <rt>Guacas</rt>  
      <rp>)</rp>
   </ruby>
</p>

MARCAS DIACRÍTICAS

En algunos idiomas se emplean marcas diacríticas para indicar la correcta pronunciación de las palabras. Algunas de estas marcas pueden ser las tildes, acentos graves, acentos agudos, diéresis, cedillas, acentos circunflejos, anillos, etc. ( ~ ́ ` ̈ Ç ^ º).

En estos casos debemos usar adecuadamente estas marcas para evitar confusiones en la pronunciación de las palabras que puedan dar lugar a ambigüedades en su significado.

Respecto a este criterio de conformidad, las palabras en español no tienen diferentes significados según su pronunciación ya que se leen tal cual están escritas. Sin embargo, para que esto sea cierto la ortografía ha de ser correcta. Una ortografía incorrecta supone un serio problema de accesibilidad ya que los lectores de pantalla interpretan (verbalizan) el contenido tal cuál está escrito, pudiendo dar lugar a pronunciaciones ininteligibles o con significado alterado. Por ejemplo, en algunas palabras un acento mal puesto varía su significado:

Médico: profesional de la medicina. Medico: primera persona del presente del verbo medicar. Medicó: tercera persona del pasado del verbo medicar.

LA INFORMACIÓN Y EL MANEJO DE LA INTERFAZ DE USUARIO DEBEN SER COMPRENSIBLES.

El objetivo de este principio es que la información y la forma de operar los elementos de interfaz de usuario sean comprensibles. Es decir, el contenido del sitio web y la forma de interactuar con él no pueden ir más allá de la capacidad de entendimiento de los usuarios.

Este principio está formado por tres pautas:

PAUTA 3.1 LEGIBLE

Hacer que los contenidos textuales resulten legibles y comprensibles.

La finalidad principal de esta pauta es asegurar que la información necesaria para comprender el documento está disponible y que el contenido textual es legible y comprensible para los usuarios y productos de apoyo.

La aplicación de esta pauta mejora la capacidad para entender el contenido por parte de personas con discapacidad y, en general, por parte de cualquier usuario de productos de apoyo.

PAUTA 3.2 PREDECIBLE

Hacer que las páginas web aparezcan y operen de manera predecible.

El objetivo de esta pauta es presentar el contenido de forma predecible entre las diferentes páginas del sitio web, así como hacer que el comportamiento de los componentes interactivos y funcionales sea también predecible.

El presentar el contenido y la funcionalidad de forma predecible es debido a que los usuarios con discapacidad tienen dificultades añadidas para la comprensión de las páginas web. Por ejemplo:

• Los lectores de pantalla leen contenido de forma secuencial lo que dificulta la comprensión de las relaciones espaciales.
• Los usuarios de magnificadores de pantalla sólo perciben parte del contenido, perdiendo la información de contexto y los cambios producidos en el resto del contenido fuera del área de visión.
• Las personas con problemas cognitivos sufren desorientación cuando la navegación no tiene un comportamiento predecible.

PAUTA 3.3 ENTRADA DE DATOS ASISTIDA

Ayudar a los usuarios a evitar y corregir los errores.

El objetivo es reducir el número de errores importantes o irreversibles que se pueden producir al interactuar con el sitio web e informar y ayudar a los usuarios a corregir los errores en caso de que se produzcan.

Si bien nadie está libre de cometer algún error a la hora de interactuar con un sitio web o al introducir datos en un formulario, las personas con discapacidad son más propensas a cometer errores y encuentran más dificultades para detectarlos y corregirlos.

Por otra parte, los mecanismos empleados habitualmente para informar sobre los errores producidos no suelen ser obvios para las personas con discapacidad (campo de visión reducido, problemas en la percepción de colores, uso de lectores de pantalla y otras ayudas técnicas que acceden al documento de forma secuencial, etc.).

En esta pauta de trata de evitar que los usuarios cometan errores y, en caso de que se produzcan, informar adecuadamente y ayudar a corregirlos.

Cuando cualquier componente recibe el foco, no inicia ningún cambio en el contexto.

Objetivo:

Asegurar que la funcionalidad es predecible cuando se navega por los documentos.

Se entiende por cambio de contexto un cambio importante en el contenido de la página que, si se realiza sin avisar, puede desorientar a los usuarios que no pueden ver todo el contenido de la página de forma simultánea.

Esto incluye cambios de:

• Agente de usuario: el cambio de agente de usuario activo se considera un cambio de contexto. Por ejemplo, abrir un gestor de correo, un lector de documentos PDF, etc.
• Vista (área de visualización): el cambio del área donde se visualiza el contenido (ventanas y pestañas del navegador, marcos, etc.) también se considera un cambio de contexto.
• Foco: cambiar el foco de un elemento a otro es un cambio de contexto.
• Contenido que cambia el significado de la página: cuando cambia el contenido de la página de forma que se altera el significado principal de la misma, se está produciendo un cambio de contexto. Por ejemplo, se considera un cambio de contexto ir a una página nueva o un cambio de contenido tal que parezca que se ha ido a una página nueva. También se considera un cambio de contexto el cambio en el orden del contenido de la página.

Un cambio de contenido no es siempre un cambio de contexto a no ser que cambie algo de lo anterior.

Algunos ejemplos de cambios de contexto pueden ser:

• Envío de un formulario de forma automática cuando un componente recibe o pierde el foco.
• Apertura de nueva ventana cuando un elemento recibe el foco.
• Cambio del foco a otro componente cuando un componente recibe el foco.

Por otra parte, no se consideran cambios de contexto:

• Expandir un submenú en el menú de navegación.
• Expandir parte de contenido previamente oculto como, por ejemplo, las respuestas a las preguntas de un FAQ.
• El uso de pestañas para alternar entre diferentes partes del contenido de la página.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales, motrices o limitaciones cognitivas.

¿CÓMO CUMPLIR?

USAR UNA ACCIÓN EN VEZ DEL FOCO PARA CAMBIOS DE CONTEXTO

Debemos realizar cambios de contexto únicamente cuando los usuarios realicen alguna acción que usualmente se use para solicitar un cambio de contexto. Por ejemplo, hacer clic en un enlace o presionar un botón de envío.

Por ejemplo, si usamos el evento onfocus en un enlace para abrir una nueva ventana del navegador esta se abrirá en cuanto el enlace reciba el foco (por ejemplo, al tabular con el teclado) sin que el usuario haya solicitado activar el enlace.

Ejemplo incorrecto:

<a href="help.html" onfocus="openWindow(this.href); return false"> 
   Ayuda (nueva ventana) 
</a>

Si, por el contrario, abrimos la nueva ventana avisando de la apertura en el texto del enlace y mediante el evento onclick el usuario puede decidir si quiere activar el enlace o no.

Ejemplo correcto:

<a href="help.html" onclick="openWindow(this.href); return false"> 
   Ayuda (nueva ventana) 
</a>

En este ejemplo vemos que el cambio de contexto sólo se produce si el usuario lo solicita expresamente haciendo clic o pulsando la tecla enter o barra espaciadora.

Algunos fallos comunes a la hora de provocar un cambio de contexto son:

• Abrir una nueva ventana al cargar la página. Esto se suele usar para incluir anuncios en los sitios web y obligar a los usuarios que los vean. Sin embargo puede provocar desorientación en algunos grupos de usuarios.
• Usar scripts para eliminar el foco de un elemento en cuanto lo recibe. Esto se hace a veces para evitar que sea visible el indicador de foco, pero este indicador es útil para usuarios de teclado. Además. se imposibilita también el acceso al elemento mediante el teclado. Sólo es posible la interacción con el ratón.

El cambio de estado en cualquier componente de la interfaz de usuario no provoca automáticamente un cambio en el contexto a menos que el usuario haya sido advertido de ese comportamiento antes de usar el componente.

Objetivo:

Asegurar que introducir datos o seleccionar un control tiene efectos predecibles.

Cuando hablamos de cambio del estado de un componente de interfaz de usuario nos estamos refiriendo a cambiar su configuración o valor, de forma que éste persista cuando el usuario no interactúe más con él. Esto se entiende mejor con algunos ejemplos:

• Activar o desactivar una casilla de selección (checkbox).
• Escribir en un campo de texto.
• Seleccionar una opción en un menú de selección (select).

Según este criterio de conformidad no podemos provocar cambios de contexto cuando cambiamos el estado de un componente de interfaz de usuario a no ser que previamente se avise de este comportamiento.

Por el contrario, no se considera un cambio de estado el activar un enlace, presionar un botón, usar un menú de navegación, etc. Esto se consideran acciones y, por tanto, se pueden provocar cambios de contexto a partir de las mismas, como vimos en el criterio de conformidad 3.2.1.

Por ejemplo, si en un formulario existen campos que al acabar de rellenarlos se desplaza el foco de forma automática al siguiente campo entonces se está produciendo un cambio de contexto (cambio del foco). Esto es bastante habitual en los campos para introducir fechas, donde al acabar de introducir los dos dígitos del día el foco avanza automáticamente al campo del mes y, una vez rellenado, al del año. Este es un ejemplo de mala práctica a no ser que se avise previamente al usuario del comportamiento de dichos campos.

Supongamos ahora que tenemos un campo de selección que, según la opción escogida, muestre un contenido u otro.

Por ejemplo, en un formulario de compra de un seguro nos pregunta si tenemos algún seguro anterior comprado con el proveedor. Si respondemos que "no" entonces no pregunta nada más al respecto.

Sin embargo, si respondemos que sí tenemos un seguro anterior, entonces muestra unos campos nuevos en el formulario para preguntarnos datos sobre ese seguro. En este caso no se está produciendo un cambio de contexto porque, aunque se incluya una parte con contenido nuevo, no se está cambiando el significado de la página.

Beneficiarios

:

Beneficia especialmente a personas con discapacidades visuales o limitaciones cognitivas.

¿CÓMO CUMPLIR?

Para cumplir este criterio de conformidad podemos hacer que los cambios de contexto se produzcan por acciones del usuario mediante botones de envío o bien, en su defecto, describir previamente qué es lo que ocurrirá para que los usuarios estén informados.

BOTÓN DE ENVÍO PARA INICIAR UN CAMBIO DE CONTEXTO

Proporcionar un botón de envío permite a los usuarios solicitar cambios de contexto de forma explícita.

Botón de envío en HTML para enviar formularios

Los formularios deben tener un botón de envío estándar (<input> de tipo "submit", <input> de tipo "image" o <button> de tipo "submit") para enviar todos los datos del formulario.

Por ejemplo, no debemos enviar los datos de un formulario de forma automática al acabar de rellenar el último campo y presentar una nueva página, ya que esto provoca un cambio de contexto no solicitado por el usuario.

En ocasiones se usan menús de selección (<select>) como mecanismos de navegación entre páginas. En estos casos, en vez de usar los eventos onfocus u onchange para provocar el cambio de contexto debemos incluir un botón de envío para que dicho cambio de contexto se realice a partir de una acción (solicitud) del usuario.

Los eventos onfocus y onchange, además de provocar un cambio de contexto no esperado o no solicitado, se disparan al navegar entre las opciones mediante el teclado. Los usuarios de teclado no podrán escoger qué página desean ver y sólo podrán ir a la primera de la lista.

DESCRIBIR PREVIAMENTE LO QUÉ OCURRIRÁ

En caso de que no incluyamos un botón de envío entonces debemos incluir una descripción de lo que ocurrirá cuando un cambio en el estado de un control de formulario provoca un cambio de contexto.

Obviamente, esta información debe proporcionarse antes de que el control de formulario provoque el cambio de contexto.

Algunos fallos comunes son:

• Tras rellenar el último campo, enviar un formulario de forma automática y presentar nuevo contenido sin haber avisado previamente.
• Abrir una ventana nueva cuando cambia el estado de una casilla de selección (checkbox), botón de radio (radio button) o menú de selección (select) sin avisar previamente a los usuarios.
• Situar la información de ayuda que avisa sobre los cambios de contexto, producidos al cambiar el estado de algún componente de interfaz de usuario, en un lugar que podría ser pasado por alto

Los mecanismos de navegación que se repiten en múltiples páginas web dentro de un conjunto de páginas web aparecen siempre en el mismo orden relativo cada vez que se repiten, a menos que el cambio sea provocado por el propio usuario.

Objetivo:

Asegurar que la presentación y la maquetación son consistentes a lo largo de todo el sitio web.

Una navegación coherente es útil para los usuarios que interactúan con contenidos repetidos en un conjunto de páginas web y que necesitan localizar una funcionalidad o información específica más de una vez. Por ejemplo, para los usuarios de lectores de pantalla es importante que puedan localizar fácilmente los menús de navegación y secciones de contenido a lo largo de las diferentes páginas de un sitio web.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales o limitaciones cognitivas.

¿CÓMO CUMPLIR?

MANTENER EL MISMO ORDEN RELATIVO PARA LOS ELEMENTOS QUE SE REPITAN A LO LARGO DEL SITIO

Cuando hablamos de mantener el orden relativo nos referimos a la posición relativa respecto a otros elementos.

Se pueden incluir o eliminar elementos en la secuencia siempre que se mantenga el orden relativo entre el resto de elementos. Por ejemplo, en un menú de navegación los enlaces deben mantener todos el mismo orden entre sí. Se considera que este orden relativo se mantiene incluso si se añaden otros enlaces como parte de un submenú en una sección.

Por tanto, este criterio de conformidad no impide usar menús o bloques de navegación secundarios que se actualicen según se avance por la navegación en el sitio web. La navegación se puede ir adaptando a las necesidades del sitio de forma coherente.

Por ejemplo, debemos situar el menú de utilidades siempre en el mismo lugar, y no en una páginas situarlo en la cabecera y en otras páginas situarlo en el pie de la página. Los enlaces del menú de utilidades deben mantener a su vez el mismo orden entre sí.

Los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas web son identificados de manera coherente.

Objetivo:

Identificar de forma consistente los componentes funcionales que se repiten en un conjunto de páginas web. Si la misma función tiene diferentes etiquetas a lo largo del sitio, el sitio es mucho más difícil de usar.

Un sitio web en el que se usen diferentes etiquetas para una misma función dificulta considerablemente su uso.

Puede provocar confusión a personas con problemas cognitivos. También a aquellos usuarios que al navegar dependen fundamentalmente de su familiaridad con las funcionalidades del sitio web, como los usuarios de lectores de pantalla.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales o limitaciones cognitivas.

¿CÓMO CUMPLIR?

ETIQUETAS, NOMBRES Y ALTERNATIVAS TEXTUALES CONSISTENTES PARA CONTENIDO CON LA MISMA FUNCIONALIDAD DEBEMOS USAR NOMBRES Y TEXTOS CONSISTENTES PARA REFERIRNOS A CONTENIDOS QUE TENGAN LA MISMA FUNCIONALIDAD.

• Usar las mismas etiquetas para los mismos controles de formulario. Por ejemplo, en un formulario de autenticación no usar diferentes etiquetas a lo largo del sitio para indicar el usuario (usuario, login, nombre,...) o la contraseña (contraseña, clave, password,...).
• En los enlaces usar el mismo texto para el mismo destino.
• Usar textos consistentes para destinos similares. Por ejemplo, en una colección de documentos paginados, los 8enlaces usados para ir al siguiente documento pueden ser diferentes, pero mantienen una consistencia entre sí ("Página 1", "Página 2", "Página 3", etc.).

Esto también es aplicable a las alternativas textuales de los iconos usados en el sitio web y que tengan la misma funcionalidad.

Así, por ejemplo, si un icono se emplea para indicar un enlace a la página de inicio, su texto alternativo debe indicar esta funcionalidad y ser consistente a lo largo de todo el sitio web.

Hay que señalar que consistente no quiere decir idéntico. Por ejemplo, la imagen de una flecha para avanzar a la página siguiente puede tener diferentes textos alternativos, aunque consistentes, en cada página: "Ir a página 4", "Ir a página 5", etc.

Un mismo icono puede tener varias funciones diferentes. En ese caso se pueden usar diferentes textos alternativos según su función, pero de forma consistentes para cada función. Por ejemplo, la imagen de una marca de selección (como un checkbox seleccionado) puede usarse para indicar diferentes significados: "completado", "correcto", "seleccionado", etc.

Además, a la hora de proporcionar etiquetas, nombres y alternativas textuales, debemos aplicar también los criterios de conformidad:

• 1.1.1: Contenido no textual.
• 4.1.2: Nombre, rol y valor (que se verá más adelante)

Los cambios en el contexto son iniciados únicamente a solicitud del usuario o se proporciona un mecanismo para detener tales cambios.

Objetivo:

Evitar la confusión que producen los cambios de contexto inesperados dando a los usuarios un control total sobre los mismos.

Los cambios de contexto inesperados generan dificultades a personas con determinadas discapacidades, como baja visión, ceguera o limitaciones cognitivas. El objetivo de este criterio de conformidad es evitar la confusión que 9puede provocar la aparición de nuevas ventanas de forma automática, el envío automático de formularios, actualizaciones y refrescos de página, etc.

Hacer clic en un enlace es un ejemplo de acción que se "inicia sólo bajo petición del usuario".

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales o limitaciones cognitivas.

¿CÓMO CUMPLIR?

MECANISMO PARA SOLICITAR ACTUALIZACIONES DE PÁGINA

Las actualizaciones de página han de realizarse bajo petición de los usuarios. Si la página contiene información que requiera actualizarse cada cierto tiempo para mantener su validez entonces, en lugar de hacerlo automáticamente, debemos informar de ello a los usuarios y proporcionar un mecanismo que les permita solicitar dicha actualización.

EJEMPLO:

<a href="noticias.jsp">Actualizar esta página</a>

Las actualizaciones automáticas, además de generar confusión en ciertos usuarios, provocan que el cursor virtual que usa el lector de pantalla para recorrer el documento vuelva al inicio de la página, reiniciando continuamente la lectura de la misma.

REDIRECCIONES DE PÁGINA TRANSPARENTES A LOS USUARIOS

Las redirecciones automáticas han de hacerse de forma que sean transparentes a los usuarios para evitar que las perciban como un cambio de contexto. Para ello podemos usar redirecciones del lado del servidor, en lugar de usar redirecciones de cliente. En caso de usar redirecciones en el cliente han de ser inmediatas, sin límite de tiempo, para que sean transparentes a los usuarios.

Redirecciones automáticas de servidor

A continuación se muestra cómo realizar una redirección usando la configuración del servidor para indicar el código de estado HTTP apropiado (301). En el ejemplo mostrado se usa una directiva del servidor Apache.

Ejemplo:

redirect 301 /antigua.jsp /nueva.jsp

También podemos emplear un lenguaje de servidor para realizar las redirecciones automáticas. En el siguiente ejemplo se muestra cómo realizarlo mediante PHP.

Ejemplo:

<?php 
header("HTTP/1.1 301 Moved Permanently"); 
header("Location: http://www.dominio.com/nueva.jsp"); 
?> 

Redirecciones en el cliente instantáneas

Las redirecciones de cliente en las que se establece un periodo de tiempo antes de realizar la redirección no son transparentes al usuario. Se muestra primero la página original y después de un periodo de tiempo se realiza la redirección. Dicho tiempo puede ser insuficiente para que los usuarios lean el contenido de la página, especialmente los usuarios de lectores de pantalla, y percatarse de que se va a producir una redirección. Por otra parte, este tipo de redirecciones entorpece la funcionalidad del botón "Atrás" del navegador.

EJEMPLO INCORRECTO:

<meta http-equiv="refresh" content="60;redireccion.html" />

Siempre son preferibles las redirecciones de servidor ya que no muestran el contenido de la página antigua antes de hacer la redirección. Sin embargo, si es necesario hacer redirecciones de cliente porque no tengamos la posibilidad de usar tecnologías de servidor, estas han de ser instantáneas de forma que sean transparentes a los usuarios.

EJEMPLO:

<meta http-equiv="refresh" content="0;URL='index.html'" />  

En todo caso, la nueva página debe tener información relacionada con la página antigua.

AVISAR DE LA APERTURA DE VENTANAS EMERGENTES

Usar target y avisar en el texto del enlace

La apertura de nuevas ventanas del navegador presenta una serie de inconvenientes:

• Al cambiar la ventana actual o aparecer inesperadamente nuevas ventanas, los usuarios (independientemente de sus características) pueden sentirse desorientados.
• Al abrirse un nuevo navegador se pierde el historial de las páginas visitadas y se entorpece la navegación.
• El botón "Atrás para volver a páginas visitadas anteriormente queda inactivo al no contar con un historial en el nuevo navegador o nueva pestaña abiertos.
• En determinados navegadores, si se usan a pantalla completa, el que el botón "Atrás" se encuentre inactivo es la única pista que tienen los usuarios de que se ha abierto una nueva ventana.

Por tanto, la apertura de nuevas ventanas del navegador la realizaremos siempre bajo petición de los usuarios.

Para ello, podemos usar el atributo target para abrir la nueva ventana e informar de ello en el texto del enlace.

EJEMPLO

:

<a href="ayuda.html" target="_blank">Ayuda (en nueva ventana)</a>  

En principio, el uso del atributo target sirve para que los agentes de usuario reconozcan que se va a abrir una nueva ventana, avisen de ello a los usuarios y puedan desactivar dicha apertura si están configurados para ello.

Aún así, como no podemos asegurarnos que todos los agentes de usuario se comportarán de esa forma, debemos ser nosotros quienes avisemos a los usuarios en el texto del enlace.

Scripts como mejora progresiva

La apertura de nuevas ventanas del navegador la realizaremos siempre bajo petición de los usuarios.

Si el DTD usado no permite el uso del atributo target (por ejemplo, porque usemos un DTD de tipo Strict), o si preferimos no usarlo, podemos emplear en su lugar scripts de cliente como mejora progresiva.

Por ejemplo, podemos usar un enlace normal que no use el atributo target y que no se abra en nueva ventana.

Mediante scripts de cliente (por ejemplo, javascript) usaremos funciones DOM para añadir el evento onclick en el enlace de forma que desde este evento se llame a la función que abrirá la nueva ventana. Con el script también modificaremos el texto del enlace para avisar que se abre en nueva ventana. El código del script, en vez de incluirlo en el propio documento, lo enlazaremos desde la cabecera y lo cargaremos junto con el documento mediante el evento onload.

De esta forma, si se soportan los scripts de cliente el enlace abrirá en nueva ventana y se avisará de ello a los usuarios en el texto del enlace. Si el navegador no soporta o tiene desactivados los scripts entonces se muestra el enlace normal.

Para más información sobre DOM Scripting y JavaScript No Intrusivo se recomienda consultar:

• JavaScript No Intrusivo (http://www.onlinetools.org/articles/unobtrusivejavascript/).
• De HTML a DOM (http://icant.co.uk/articles/from-dhtml-to-dom/).
• Modelo de Objetos del Documento (http://www.w3.org/DOM/).

Este método se denomina Mejora Progresiva ya que estamos mejorando la funcionalidad de la página de forma progresiva en base al soporte de los agentes de usuario de las tecnologías empleadas (en este caso, scripts). Un navegador sólo de texto, un producto de apoyo o un navegador antiguo sin soporte de scripts mostrará el contenido original, el cual ya es correcto, pero un navegador con soporte de scripts proporcionará la funcionalidad añadida.

Evento onchange en un elemento <select> sin provocar un cambio de contexto

Podemos emplear eventos onchange en elementos <select> siempre y cuando esto no provoque un cambio de contexto.

A veces se emplean elementos <select> en los formularios de forma que, según la opción escogida, se modifican otros elementos dependientes del mismo. Por ejemplo, en un <select> podemos pedir que se seleccione un departamento y en otro <select> dependiente preguntar por una ciudad perteneciente a dicho departamento. Las opciones del segundo menú de selección dependen de la opción escogida en el primer menú de selección.

Como no se está produciendo un cambio de contexto, esta práctica sí se considera correcta (siempre que los scripts estén dentro del conjunto de las tecnologías del sitio web compatibles con la accesibilidad). Los elementos dependientes que se modifican según la opción escogida deben estar a continuación en el orden de lectura.

Un ejemplo de mala práctica en la que se produce un cambio de contexto, es usar un <select> como menú de navegación en el que se emplea onchange para abrir una nueva página según la opción escogida.

LA INFORMACIÓN Y EL MANEJO DE LA INTERFAZ DE USUARIO DEBEN SER COMPRENSIBLES.

El objetivo de este principio es que la información y la forma de operar los elementos de interfaz de usuario sean comprensibles. Es decir, el contenido del sitio web y la forma de interactuar con él no pueden ir más allá de la capacidad de entendimiento de los usuarios.

Este principio está formado por tres pautas:

PAUTA 3.1 LEGIBLE

Hacer que los contenidos textuales resulten legibles y comprensibles.

La finalidad principal de esta pauta es asegurar que la información necesaria para comprender el documento está disponible y que el contenido textual es legible y comprensible para los usuarios y productos de apoyo.

La aplicación de esta pauta mejora la capacidad para entender el contenido por parte de personas con discapacidad y, en general, por parte de cualquier usuario de productos de apoyo.

PAUTA 3.2 PREDECIBLE

Hacer que las páginas web aparezcan y operen de manera predecible.

El objetivo de esta pauta es presentar el contenido de forma predecible entre las diferentes páginas del sitio web, así como hacer que el comportamiento de los componentes interactivos y funcionales sea también predecible.

El presentar el contenido y la funcionalidad de forma predecible es debido a que los usuarios con discapacidad tienen dificultades añadidas para la comprensión de las páginas web. Por ejemplo:

• Los lectores de pantalla leen contenido de forma secuencial lo que dificulta la comprensión de las relaciones espaciales.
• Los usuarios de magnificadores de pantalla sólo perciben parte del contenido, perdiendo la información de contexto y los cambios producidos en el resto del contenido fuera del área de visión.
• Las personas con problemas cognitivos sufren desorientación cuando la navegación no tiene un comportamiento predecible.

PAUTA 3.3 ENTRADA DE DATOS ASISTIDA

Ayudar a los usuarios a evitar y corregir los errores.

El objetivo es reducir el número de errores importantes o irreversibles que se pueden producir al interactuar con el sitio web e informar y ayudar a los usuarios a corregir los errores en caso de que se produzcan.

Si bien nadie está libre de cometer algún error a la hora de interactuar con un sitio web o al introducir datos en un formulario, las personas con discapacidad son más propensas a cometer errores y encuentran más dificultades para detectarlos y corregirlos.

Por otra parte, los mecanismos empleados habitualmente para informar sobre los errores producidos no suelen ser obvios para las personas con discapacidad (campo de visión reducido, problemas en la percepción de colores, uso de lectores de pantalla y otras ayudas técnicas que acceden al documento de forma secuencial, etc.).

En esta pauta de trata de evitar que los usuarios cometan errores y, en caso de que se produzcan, informar adecuadamente y ayudar a corregirlos.

Si se detecta automáticamente un error en la entrada de datos, el elemento erróneo es identificado y el error se describe al usuario mediante un texto.

Objetivo:

Asegurar que los usuarios se percatan de que se ha producido un error y dónde.

Hemos de informar en formato de texto acerca de los errores producidos al introducir datos en un formulario. Un formulario que sólo indique los campos en los que se han producido errores mediante una marca no es suficiente. Por ejemplo, un usuario de un lector de pantalla se encontraría con los siguientes problemas:

• No sabría que se ha producido un error hasta que el lector de pantalla encuentre dichas marcas.
• Podría abandonar el formulario, antes de encontrar el error, pensando que el formulario no es funcional.

Para indicar los errores se pueden usar imágenes, colores, estilos de texto, etc., pero siempre de forma complementaria a la información proporcionara en formato textual.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales (ceguera, ceguera al color, baja visión, etc.) o limitaciones cognitivas, de lectura o aprendizaje.

¿CÓMO CUMPLIR?

Básicamente, se trata de avisar en formato de texto de los errores producidos, tanto por la ausencia de campos obligatorios como porque los datos introducidos no respeten un determinado formato o valor.

PROPORCIONAR DESCRIPCIONES TEXTUALES QUE IDENTIFIQUEN LOS CAMPOS NO COMPLETADOS

El objetivo es indicar mediante texto qué campos obligatorios son los que faltan por completar. No es suficiente con incluir marcas como asteriscos o indicaciones de color.

Tenemos dos opciones:

• Validar en el lado del cliente y mostrar un mensaje en texto o una ventana de alerta con la información necesaria.
• Validar en el lado del servidor y mostrar de nuevo el formulario informando al inicio cuáles son los campos que faltan por completar. En el formulario se deben incluir todos los datos que ya se han introducido correctamente.

PROPORCIONAR UN TEXTO DESCRIPTIVO QUE INDIQUE AL USUARIO QUE HA INTRODUCIDO UN DATO QUE NO ESTÁ EN LA LISTA DE VALORES PERMITIDOS

Cuando el usuario comete un error por introducir un valor incorrecto (el valor introducido no está entre los posibles) tenemos que:

• Validar (cliente y/o servidor) e informar mediante texto de los errores existentes al comienzo del formulario .
• Describir la naturaleza del problema y proporcionar un medio para localizar rápidamente los campos con error. Por ejemplo, un enlace desde la descripción del error al campo correspondiente.
• Si es posible, indicar los valores posibles o sugerir un valor de entre los permitidos que se asemeje al introducido

PROPORCIONAR UN TEXTO DESCRIPTIVO QUE INDIQUE AL USUARIO QUE HA INTRODUCIDO UN DATO QUE NO CUMPLE EL FORMATO REQUERIDO

De forma similar al caso anterior, cuando el usuario introduce datos que no cumplen un determinado formato (por ejemplo, para las fechas) debemos:

• Describir el error, cómo es el formato requerido y dar instrucciones para introducir el dato de forma correcta. Por ejemplo, indicar el formato de las fechas: dd/mm/aaa .
• Si es posible, dar ejemplos de datos correctos y sugerir algunos posibles similares al introducido.

VENTANA DE ALERTA AVISANDO DEL ERROR CUANDO SE USA VALIDACIÓN DE CLIENTE

Si realizamos validación de cliente, una forma de informar de los campos que faltan por completar o que se han introducido en un formato incorrecto es proporcionar una descripción de los errores en una ventana de alerta.

Una vez que el usuario cierra la ventana de alerta, resulta útil posicionar el foco sobre el campo en el que se ha producido el error.

AVISAR DE LOS ERRORES MEDIANTE EL USO DEL DOM CUANDO SE USA VALIDACIÓN DE CLIENTE

De igual forma que en el caso anterior, si realizamos validación de cliente podemos informar de los errores producidos proporcionando una descripción en forma de texto al comienzo del formulario mediante el uso de scripts para manipular el contenido del documento a través del DOM (Modelo de Objetos del Documento).

Ejemplo:

var labelError = document.createElement('label'); 
var error = '¡El formato de la fecha ha de ser(día/mes/año): ej. 13/12/1972!'; 
var textError = document.createTextNode(error); 
labelError.appendChild(textError); 
var form = document.getElementsByTagName('form')[0]; 
form.insertBefore(labelError,form.firstChild);

Se proporcionan etiquetas o instrucciones cuando el contenido requiere la introducción de datos por parte del usuario.

Objetivo

:

Evitar que se produzcan errores al introducir datos

Las personas con discapacidad tienen más posibilidades de cometer errores a la hora de interactuar con el sitio web y de rellenar formularios. Asimismo, como ya vimos, la identificación y corrección de dichos errores les resulta más complicado de lo normal.

Este tipo de usuarios depende especialmente de que se explique adecuadamente cómo se tienen que rellenar los formularios: campos obligatorios, valores posibles, formato de los datos, etc. Por tanto, debemos proporcionar la información que sea necesaria para que puedan rellenar los formularios correctamente sin cometer errores.

Esta información hemos de proporcionarla de forma clara y precisa, en su justa medida. Demasiada información, o información ambigua o imprecisa, puede llegar a ser contraproducente al generar confusión.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales (que usen lectores o magnificadores de pantalla) o limitaciones cognitivas, de lectura o aprendizaje.

¿CÓMO CUMPLIR?

PROPORCIONAR ETIQUETAS DESCRIPTIVAS

De forma general, todos los componentes de interacción deben tener etiquetas que describan su propósito de forma clara, independientemente de la tecnología que usemos para crear los formularios.

A la hora de crear o situar las etiquetas de forma que proporcionen la información necesaria, sean claras y se relacionen correctamente con los controles de formulario correspondientes, tenemos las siguientes posibilidades:

Indicar el formato de los datos y un ejemplo

Cuando los datos deben respetar un determinado formato podemos informar a los usuarios acerca de las restricciones de dicho formato en las etiquetas de los controles. Podemos además usar ejemplos para facilitar la comprensión de los formatos.

Ejemplo:

<label for="fecha">Fecha (dd/mm/aaaa)</label> 
<input type="text" name="fecha" id="date" />

Es recomendable que en los casos para los que es habitual usar diferentes formatos (por ejemplo, el formato de las fechas y horas puede variar según el país) demos varias opciones para que los usuarios escojan el formato de su preferencia.

Proporcionar instrucciones textuales al comienzo del formulario o grupo de controles describiendo las restricciones de los campos .

Una forma de ayudar a los usuarios a evitar cometer errores al introducir datos es proporcionar instrucciones en formato de texto al comienzo de los formularios. Esta técnica es más útil en formularios pequeños donde varios campos tienen restricciones similares. Es mejor que repetir la misma información para cada campo.

Por ejemplo, algunos ejemplos de instrucciones que se suelen dar son:

• "El formato de las fechas debe ser: dd/mm/aaaa"
• "Los números de teléfono sólo deben contener números sin espacios"
• "Los campos obligatorios se marcan con un asterisco (*)"
• Etc.

Situar las etiquetas de forma que las relaciones sean obvias

Cuando las etiquetas están situadas visualmente donde se espera, es más fácil entender los formularios.

Las etiquetas deben estar visibles y situadas según las siguientes reglas:

• Para los botones de radio (radio buttons) y casillas de verificación (checkbox), inmediatamente a continuación.
• Si el campo no es un botón de radio ni una casilla de verificación, inmediatamente antes del campo (a la izquierda o encima del mismo, según cómo sea la maquetación).

Proporcionar descripciones textuales que identifiquen los campos no completados

Como ya vimos en el criterio de conformidad 3.3.1, cuando se han producido errores porque falta algún dato obligatorio, tenemos que indicar mediante texto que campos son los que faltan por completar.

Para que la información sea clara y la puedan entender todos los usuarios se ha de proporcionar en forma de texto, considerándose insuficiente el incluir únicamente marcas como asteriscos o indicaciones de color.

USAR ELEMENTOS <label> PARA ASOCIAR LAS ETIQUETAS CON LOS CONTROLES DE FORMULARIO

En (X)HTML el elemento <label> sirve para marcar el texto que funciona como etiqueta de los controles de formulario. Para establecer una relación de uno a uno entre la etiqueta y el control de formulario debemos asociarla explícitamente usando el atributo for. El valor de este atributo debe ser igual al valor del atributo id del control del formulario. El valor del atributo id debe ser único.

Se deben usar elementos <label> para los elementos <textarea>, <select> e <input> de tipo "text", "checkbox", "radio", "file" y "password" .

No se usa para los siguientes elementos:

• <button>: se usa su contenido como etiqueta.
• <input> de tipo "image": se usa el atributo alt como etiqueta.
• <input> de tipo "submit" y "reset": se usa el atributo value como etiqueta.
• <input> de tipo "hidden": no se usa etiqueta
• El elemento <label> debe identificar adecuadamente el control de formulario y debe situarse:

Antes del control para elementos <input> de tipo "text", "file", "password" y para <textarea> y <select>

Después del control para elementos <input> de tipo "checkbox" y "radio"

A continuación se muestra un ejemplo en el que se realiza asociación explícita entre la etiqueta y el control de formulario.

Ejemplo:

<label for="nombre">nombre: </label> 
<input type="text" id="nombre" name="nombre" /> 

Mientras que para el criterio de conformidad 1.3.1 no es necesario que el elemento <label> sea visible (podemos ocultarlo con CSS), para cumplir el criterio de conformidad 3.3.2 es obligatorio que sí sea visible ya que sirve para proporcionar ayuda a todos los usuarios para comprender el propósito del campo.

USAR EL ATRIBUTO title PARA IDENTIFICAR LOS CONTROLES DE FORMULARIO CUANDO NO SE PUEDA USAR EL ELEMENTO <label>

Podemos usar el atributo title para etiquetar los controles de formulario e identificar su propósito cuando no usemos el elemento <label>. Por ejemplo, cuando en el diseño de la página no existe un texto que pueda etiquetarse como <label> o cuando el mostrar una etiqueta puede generar confusión.

Si no hay un elemento <label> los lectores de pantalla, y los agentes de usuario en general, pueden leer o mostrar el valor del atributo title.

Por ejemplo, si usamos tres campos para solicitar una fecha (día, mes y año) podemos usar el atributo title para identificar cada control en vez de incluir una etiqueta para cada uno.

Ejemplo:

<fieldset> 
<legend>Fecha de nacimiento:</legend> 
   <input name="dia"  type="text" 
   title="Día (dos dígitos)" size="2" /> / 
   <input name="mes"  type="text" 
   title="Mes (dos dígitos)" size="2" /> / 
   <input name="anio" type="text" 
   title="Año (cuatro dígitos)" size="4" />   
</fieldset>

En todo caso, siempre que podamos, es preferible que usemos el elemento <label> en vez de únicamente el atributo title. En caso de usar únicamente el atributo title tenemos que asegurarnos que se entiende claramente la función del control de formulario aunque no haya una etiqueta visible.

PROPORCIONAR UNA DESCRIPCIÓN DE LOS GRUPOS DE CONTROLES DE FORMULARIO USANDO LOS ELEMENTOS <fieldset> y <legend>

Cuando en un formulario existan varios grupos de controles de formulario relacionados entre sí cada grupo debe estar contenido dentro de un elemento <fieldset>. Asimismo, cada elemento <fieldset> debe tener un elemento <legend> donde se incluya la descripción del grupo de controles.

Esto se debe realizar siempre que existan grupos de controles de formulario relacionados, pero es especialmente importante para los grupos de controles de tipo "radio" y "checkbox" (con el mismo valor en el atributo name).

Ejemplo:

<fieldset> 
<legend>Opciones Especiales</legend>
  <input id="opt1" type="checkbox" 
   name="extras" value="az_met" /> 
  <label for="opt1">Azul metalizado</label> 
  <input id="opt2" type="checkbox" 
   name="extras" value="rj_vel" /> 
  <label for="opt2">Rojo velvet</label>  
  <input id="opt3" type="checkbox" 
    name="extras" value="gr_rat" /> 
  <label for="opt3">Gris ratón</label> 
</fieldset>

Para que esta técnica resulte efectiva se recomienda evitar la anidación excesiva de diferentes grupos de controles de formulario.

El elemento <fieldset> muestra por defecto una línea que rodea a los controles para que se puedan reconocer visualmente. Mediante CSS podemos modificar su presentación, pero en dicho caso se recomienda mantener la agrupación visual de los controles.

Si en el formulario existen pocos controles, no hay grupos de controles, y los controles están claramente identificados mediante el elemento <label> entonces no es necesario usar <fieldset>.

USAR UN BOTÓN ADYACENTE PARA IDENTIFICAR EL PROPÓSITO DEL CAMPO

Como caso excepcional, podemos usar un botón como etiqueta de un campo de formulario si se cumplen las siguientes condiciones:

• El botón invoca a una función relacionada con el campo de formulario.
• El botón tienen un texto que lo describe claramente.
• El botón está situado junto al campo de formulario, tanto en la presentación visual como en el orden de lectura (código de la página)

Por ejemplo, un campo donde se introduce el término a buscar en un buscador. Si dicho campo está situado junto al botón para realizar la búsqueda y éste tiene un texto descriptivo, podemos considerar que el botón sirve como etiqueta del campo de formulario.

Aún así, siempre que se pueda es más recomendable usar el elemento <label> para proporcionar etiquetas de forma explícita a los controles de formulario.

Si se detecta automáticamente un error en la entrada de datos y se dispone de sugerencias para hacer la corrección, entonces se presentan las sugerencias al usuario, a menos que esto ponga en riesgo la seguridad o el propósito del contenido.

Objetivo:

Asegurar, siempre que sea posible, que los usuarios reciben sugerencias adecuadas para corregir errores al introducir datos.

Los criterios de conformidad anteriores nos pedían etiquetar adecuadamente los campos de formulario para facilitar la introducción de datos o identificar los errores en caso de que se produzcan. Sin embargo, algunos usuarios pueden tener dificultades para saber cómo corregir los errores, y pueden abandonar los formularios aunque sepan que se han producido errores.

Este criterio de conformidad nos pide que proporcionemos a los usuarios la información necesaria para que sepan cómo corregir los errores producidos.

Beneficiarios:

Beneficia especialmente a personas con discapacidades visuales o limitaciones cognitivas y de aprendizaje.

¿CÓMO CUMPLIR?

Para proporcionar información acerca de cómo corregir un error podemos usar alguna de las técnicas que vimos anteriormente para informar sobre la presencia de errores en los formularios:

• Proporcionar descripciones textuales que identifiquen los campos no completados.
• Proporcionar un texto descriptivo que indique al usuario que ha introducido un dato que no cumple el formato requerido.
• Proporcionar un texto descriptivo que indique al usuario que ha introducido un dato que no está en la lista de valores permitidos.
• Ventana de alerta avisando del error cuando se usa validación de cliente.
• Avisar de los errores mediante el uso del DOM cuando se usa validación de cliente.

Si las descripciones de los errores son lo suficientemente explicativas pueden servir para que los usuarios sepan cómo corregir dichos errores.

Sin embargo, siempre que podamos, es recomendable incluir sugerencias para la corrección de errores.

SUGERIR UN TEXTO CON LA CORRECCIÓN

Cuando la información proporcionada por el usuario es incorrecta pero conocemos un posible valor correcto entonces podemos sugerir un texto con la corrección.

Las sugerencias o los enlaces a las mismas se deben situar de forma que sean fácilmente localizables por el usuario, cerca del campo de formulario donde se ha producido el error. Por ejemplo, al comienzo del formulario o justo antes o después del campo de formulario.

Algunos ejemplos de sugerencias pueden ser:

• Correcciones ortográficas.
• Valor similar dentro de un conjunto de valores posibles. Por ejemplo, nombres de ciudades o departamentos similares al introducido por el usuario.
• Preguntas adicionales para refinar datos ambiguos. Por ejemplo, "Washington" puede referirse a la ciudad o al estado; la "Plaza de Bolivar" puede ser la situada en Pereira o en Bogotá, etc.
• Alternativas similares para evitar repetición de valores. Por ejemplo, al registrarse en un servicio online si el nombre de usuario ya existe podemos sugerir uno similar que esté libre.

Para las páginas web que representan para el usuario compromisos legales o transacciones financieras; que modifican o eliminan datos controlables por el usuario en sistemas de almacenamiento de datos; o que envían las respuestas del usuario a una prueba, se cumple al menos uno de los siguientes casos.

Reversible: El envío es reversible.

Revisado: Se verifica la información para detectar errores en la entrada de datos y se proporciona al usuario una oportunidad de corregirlos.

Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes de finalizar el envío de los datos.

Objetivo:

Evitar graves consecuencias como resultado de un error al realizar una acción que no se puede deshacer.

Si un error a la hora de realizar un proceso en linea ya es de por sí un problema que debemos evitar, es aún más importante cuando dicho error puede tener importantes implicaciones legales o económicas:

Pagos y devoluciones con carácter legal como el pago de impuestos, tasas, multas, devoluciones fiscales, etc.

Transacciones económicas en general.

Modificación o borrado de datos del usuario, como cuentas o perfiles de usuario, información personal, información legal, documentos personales, etc.

Si este tipo de transacciones tienen lugar inmediatamente y no se pueden deshacer pueden tener importantes y costosas consecuencias. Por ejemplo:

• Comprar billetes de avión sin posibilidad de devolución y tener un error al introducir la fecha del viaje.
• Comprar en una tienda online y equivocarse en la cantidad de productos pedidos (por ejemplo, en vez de "1" poner "11")

Por tanto, en una transacción de este tipo, debemos dar al menos la posibilidad de revisar la información antes de enviarla para la confirmación o corrección de los posibles errores detectados.

Beneficiarios:

Evitar las consecuencias de los errores beneficia a todos los usuarios.

¿CÓMO CUMPLIR?

EN TRANSACCIONES DE CARÁCTER LEGAL O ECONÓMICO

Si la aplicación produce que ocurra una transacción de carácter legal o económico, como realizar una compra o presentar una declaración de impuestos, tenemos las siguientes opciones.

Ofrecer un periodo de tiempo tras el envío durante el cual se pueda modificar o cancelar por el usuario

Para permitir a los usuarios corregir los errores podemos ofrecer un periodo de tiempo durante el cual se pueda cancelar o cambiar la acción realizada.

En este caso, debemos informar del tiempo disponible para realizar las modificaciones. De igual forma, debemos describir el proceso necesario para modificar o cancelar el pedido. Esta modificación o cancelación no tiene por que ser necesariamente parte del proceso en línea, pudiendo emplearse otras vías como el correo electrónico o el teléfono, por ejemplo.

Permitir a los usuarios revisar y corregir los datos antes del envío

Si no podemos facilitar un periodo de tiempo para cancelar o modificar el envío, podemos proporcionar a los usuarios un mecanismo para asegurarse de que los datos que han introducido son correctos antes de que sean enviados y ya no se puedan modificar.

En un formulario de un solo paso, en el que todos los datos que se van a enviar se pueden ver en una misma página, no tendríamos que hacer nada especial ya que el usuario puede revisar fácilmente todos los datos antes de enviarlos.

Por el contrario, en formularios de varios pasos debemos cumplir algunas de las siguientes condiciones:

• Almacenar los datos en cada paso y permitir a los usuarios retroceder a un paso anterior para ver y/o modificar los datos introducidos.
• Al terminar el último paso, proporcionar un resumen con todos los datos antes de realizar la transacción, sugerir al usuario que los revise y permitirle corregir los errores si es necesario.

Proporcionar, además del botón de envío, una casilla de verificación (checkbox) para confirmar

Con esta técnica conseguimos que los usuarios deban marcar la casilla de verificación para indicar que han revisado los datos y que estos pueden ser enviados. Esto es especialmente importante cuando los cambios no se pueden deshacer o cuando implican el borrado de datos.

La casilla de verificación debe estar situada cerca del botón de envío para que se vea fácilmente e inicialmente no tiene que estar seleccionada. De esta forma obligamos al usuario a seleccionarla para poder enviar el formulario.

El texto usado como etiqueta para la casilla de verificación debe transmitir la idea de que el usuario ha revisado y está de acuerdo con los datos introducidos antes de realizar la acción. Por ejemplo:

• "He revisado los datos y confirmo que son correctos"
• "Confirmo que deseo borrar esta cuenta"
• "He comprobado que la cantidad que quiero transferir es correcta"

Si no se selecciona la casilla de verificación el formulario no se envía y se le pide al usuario que revise los datos (estos no se pierden), seleccione la casilla de verificación y reenvíe el formulario.

SI LA ACCIÓN IMPLICA EL BORRADO DE DATOS

Si la acción que se realiza implica el borrado de datos del usuario, como cuentas o perfiles de usuario, información personal, información legal, documentos personales, etc., entonces tenemos las siguientes opciones.

Ofrecer la posibilidad de recuperar la información borrada

Si la aplicación permite el borrado de datos, podemos proporcionar un mecanismo que permita a los usuarios recuperar la información que fuese borrada por error.

Una opción es retrasar el borrado efectivo de los datos durante un periodo de tiempo, durante el cual se guardarán en un espacio reservado (como la papelera de reciclaje de algunos sistemas operativos) antes de proceder con el borrado definitivo. Durante dicho periodo se permitirá consultar y recuperar los datos borrados.

Por ejemplo, supongamos que tenemos un espacio de almacenamiento en línea donde guardamos documentos, archivos, carpetas, etc. Después de borrar un documento, éste se puede guardar en el servidor durante una semana antes de borrarlo definitivamente, permitiendo su recuperación durante ese periodo de tiempo.

Otra posibilidad es guardar los datos eliminados manteniendo un control de cambios, de forma similar al historial de cambios de un wiki. De esta forma los datos siempre podrán ser recuperados.

Solicitar una confirmación para continuar con la acción

También podemos solicitar una confirmación al usuario que la acción que está a punto de realizar es la deseada. Esta técnica debemos usarla cuando la acción no se pueda deshacer.

Al solicitar la confirmación debemos informar sobre las consecuencias de la acción. Por ejemplo "Los datos no podrán recuperarse una vez borrados". Como es obvio, debemos dar las opciones de "confirmar" o "cancelar" la acción.

A veces una confirmación es lo que esperan los usuarios. Es posible que no perciban la importancia de las consecuencias de una determinada acción hasta que no se les pide una confirmación. De esta forma se les alerta y anima a revisar los datos antes de enviarlos, y corregirlos en caso de que hubiese algún error.

Algunos ejemplos donde podemos aplicar esta técnica son:

• Solicitar confirmación antes de proceder al borrado de los mensajes de la papelera en un gestor de correo en línea.
• Avisar cuando una transacción económica, la cual implica pérdida de dinero, es irreversible y solicitar una confirmación.

Proporcionar, además del botón de envío, una casilla de verificación (checkbox) para confirmar

Como ya vimos antes, de esta forma conseguimos que los usuarios deban marcar la casilla de verificación para indicar que han revisado los datos y que estos pueden ser enviados. Esto es especialmente importante cuando los cambios no se pueden deshacer o cuando implican el borrado de datos.

La casilla de verificación debe estar situada cerca del botón de envío para que se vea fácilmente e inicialmente no tiene que estar seleccionada, obligando al usuario a seleccionarla para poder enviar el formulario.

SI SE TRATA DE UNA APLICACIÓN DE EVALUACIÓN

Si la aplicación se trata de una aplicación de evaluación como, por ejemplo, la realización de test o exámenes en línea, entonces tenemos las siguientes opciones.

Permitir a los usuarios revisar y corregir los datos antes del envío

Al igual que en al caso de las transacciones legales o económicas, si no podemos facilitar un periodo de tiempo para cancelar o modificar el envío, podemos proporcionar a los usuarios un mecanismo para que se asegure de que los datos que han introducido son correctos antes de que sean enviados y ya no se puedan modificar.

En un formulario de un solo paso, en el que todos los datos que se van a enviar se pueden ver en una misma página, no tendríamos que hacer nada especial ya que el usuario puede revisar fácilmente todos los datos antes de enviarlos.

Por el contrario, en formularios de varios pasos debemos cumplir algunas de las siguientes condiciones:

• Almacenar los datos en cada paso y permitir a los usuarios retroceder a un paso anterior para ver y/o modificar los datos introducidos.
• Al terminar el último paso, proporcionar un resumen con todos los datos antes de realizar el envío, sugerir al usuario que los revise y permitirle corregir los errores si es necesario.

Solicitar una confirmación para continuar con la acción

Como vimos antes, también podemos solicitar al usuario una confirmación de que la acción que está a punto de realizar es la deseada. Esta técnica es útil cuando la acción no se puede deshacer, como puede ser el envío de las respuestas a un examen o test en línea.

Al solicitar la confirmación debemos informar sobre las consecuencias de la acción. Por ejemplo: "Una vez enviado el test no se podrán modificar las respuestas". Como es obvio, debemos dar las opciones de "confirmar" o "cancelar" la acción.

Se proporciona ayuda dependiente del contexto.

Objetivo:

Proporcionar ayuda a los usuarios para evitar que cometan errores.

Los usuarios con discapacidad son más propensos a cometer errores que aquellos que no tienen ningún tipo de discapacidad. Proporcionar ayuda contextual para interactuar con formularios y aplicaciones ayuda a los usuarios a realizar las operaciones necesarias sin perder el contexto de la tarea que están realizando.

La ayuda contextual sólo es necesaria si las etiquetas usadas para los controles no son suficientes para describir su funcionalidad. En caso de proporcionar este tipo de ayuda, debe hacerse de tal forma que sea fácil reconocer su existencia y ubicación.

Beneficiarios:

Beneficia a personas con problemas cognitivos, de lectura y escritura, así como a personas mayores.

¿CÓMO CUMPLIR?

Para ayudar a los usuarios a evitar que cometan errores podemos usar alguna de las técnicas que vimos anteriormente para proporcionar instrucciones para introducir datos.

• Instrucciones textuales al comienzo del formulario o grupo de controles describiendo las restricciones de los campos.
• Indicar el formato de los datos y un ejemplo.

Estas instrucciones, si son lo suficientemente explicativas, pueden considerarse válidas como ayuda contextual de los formularios.

Sin embargo, siempre que sea necesario por la complejidad del formulario o de los datos a introducir, es recomendable que incluyamos información de ayuda adicional de forma explícita.

Para proporcionar la ayuda contextual tenemos las siguientes opciones.

Enlace de ayuda en cada página

La ayuda sirve a los usuarios para saber cómo introducir los datos de los formularios de forma correcta.

Para proporcionar la ayuda, en cada página que contenga formularios podemos realizar lo siguiente:

• Proporcionar al menos un enlace a la información de ayuda sobre cómo completar el formulario.
• Proporcionar un enlace antes o después de cada campo de formulario con información específica sobre dicho campo.

Al seguir los enlaces a la ayuda no se deben perder los datos ya introducidos (por ejemplo, mostrando la ayuda en una ventana nueva o en una capa).

Proporcionar ayuda mediante un asistente

Una forma de proporcionar ayuda contextual para ayudar a rellenar un formulario es mediante un asistente. Este tipo de ayuda es útil para personas con problemas cognitivos que pueden tener problemas para leer texto y les resulta más sencillo de entender el contenido visual y auditivo.

CORRECTOR ORTOGRÁFICO QUE OFREZCA SUGERENCIAS

Es habitual que las personas con problemas cognitivos tengan problemas a la hora de deletrear o escribir una palabra con la ortografía correcta. Sin embargo, pueden ser capaces de escribirla de forma "aproximadamente" correcta. Un corrector ortográfico facilita introducir los datos deseados sin necesidad de que los usuarios pierdan tiempo mediante prueba y error o buscando la forma correcta de escritura.

Esta técnica también es útil para los usuarios invidentes (que usen un lector de pantalla) o que tengan alguna discapacidad motriz, ya que facilita la corrección de los errores producidos al usar el teclado o los dispositivos de entrada que utilicen.

Por tanto, si el dato introducido no es correcto y conocemos alguna o varias alternativas similares con ortografía correcta, podemos sugerirlas y proporcionar un mecanismo sencillo para escoger alguna de ellas e introducirla en el formulario.

Por ejemplo, en un buscador si el término introducido no existe se pueden sugerir términos similares. Los términos sugeridos pueden ser enlaces que automáticamente realicen la búsqueda sobre dichos términos. Esto es similar a lo que hace el buscador de Google cuando nos sugiere alternativas al término introducido ("Quizás quiso decir: ...").

Otro ejemplo puede ser el de una compañía de viajes donde haya que introducir el nombre de una ciudad de origen y destino. Si alguno de los nombres no coincide con ninguna ciudad se pueden sugerir otras ciudades con nombres similares.

Para las páginas web que requieren al usuario el envío de información, se cumple al menos uno de los siguientes casos.

Reversible: El envío es reversible.

Controlado: Se verifica la información para detectar errores en la entrada de datos y se proporciona al usuario una oportunidad de corregirlos.

Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes de finalizar el envío de los datos.

Objetivo:

Evitar las consecuencias de cometer un error al enviar los datos de un formulario.

Este criterio de conformidad es igual que el 3.3.4 solo que aquel sólo se aplicaba a las transacciones legales, económicas o que implicasen el borrado de datos del usuario.

Este criterio de conformidad, de nivel AAA, es aplicable siempre que los usuarios tengan que enviar información, sea del tipo que sea.

Beneficiarios:

Evitar las consecuencias de los errores beneficia a todos los usuarios.

¿CÓMO CUMPLIR?

No existen técnicas adicionales para este criterio de conformidad. Se han de seguir las mismas técnicas indicadas en el criterio de conformidad 3.3.4, salvo que ahora se aplican siempre que los usuarios envíen información de cualquier tipo.