4.0Principio 4: Robusto

4.0.0Introducción

EL CONTENIDO DEBE SER SUFICIENTEMENTE ROBUSTO COMO PARA SER INTERPRETADO DE FORMA FIABLE POR UNA AMPLIA VARIEDAD DE APLICACIONES DE USUARIO, INCLUYENDO LAS AYUDAS TÉCNICAS

El objetivo de este principio es que los agentes de usuario interpreten el contenido de forma correcta. Según las tecnologías y los agentes de usuario evolucionen, el contenido debe mantenerse accesible.

Este principio está formado por una pauta:

PAUTA 4.1 COMPATIBLE

Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas.

Para que todas las medidas de accesibilidad vistas en los otros principios sean efectivas, es fundamental que aseguremos la compatibilidad del código con los agentes de usuario tanto actuales como futuros, incluyendo también los productos de apoyo.

Esto lo podemos lograr de dos formas:

  • Evitando malas prácticas que puedan provocar que los productos de apoyo no interpreten correctamente el contenido (p. ej. por usar un marcado incorrecto) o que incluso lo lleguen a ignorar (p. ej. por usar un marcado propietario)
  • Proporcionar la información en el contenido mediante marcado estándar de forma que los productos de apoyo puedan reconocer dicho contenido e interactuar con él.

4.1Principio 4 Pauta 1: Compatible

4.1.0

Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas .

Para que todas las medidas de accesibilidad vistas en los otros principios sean efectivas, es fundamental que aseguremos la compatibilidad del código con los agentes de usuario tanto actuales como futuros, incluyendo también los productos de apoyo.

4.1.1Procesamiento [Nivel A]

En los contenidos implementados mediante el uso de lenguajes de marcas, los elementos tienen las etiquetas de apertura y cierre completas; los elementos están anidados de acuerdo a sus especificaciones; los elementos no contienen atributos duplicados y los ID son únicos, excepto cuando las especificaciones permitan estas características.

Nota: Las etiquetas de apertura y cierre a las que les falte un carácter crítico para su formación, como un signo de "mayor qué", o en las que falten las comillas de apertura o cierre en el valor de un atributo, no se consideran completas.

Objetivo:

Asegurar que los agentes de usuario y productos de apoyo puedan interpretar correctamente y procesar el contenido.

Cuando hablamos de procesar el contenido nos referimos a transformar la entrada de texto en una estructura de datos adecuada para ser interpretada y manejada por los agentes de usuario. Para (X)HTML la estructura de datos usada para representar el contenido es un árbol en el que las etiquetas (elementos) son los nodos del mismo.

Cuando el código es incorrecto, los agentes de usuario suelen usar técnicas de reparación de código. Sin embargo, estas técnicas pueden variar entre unos agentes de usuario y otros, pudiendo dar lugar a resultados dispares.

Si el código no se puede procesar correctamente entonces puede ocurrir que:

Algunos agentes de usuario sean incapaces de interpretar el código y presentar el contenido.

Diferentes agentes de usuario interpreten el código de forma distinta (variando la estructura de datos) y como resultado muestren diferentes contenidos.

El concepto de bien formado es similar a lo que se pide en este criterio de conformidad, pero este término es exclusivo de XML. En HTML válido existen etiquetas de cierre opcionales y, por tanto, no es necesario que esté bien formado.

¿CÓMO CUMPLIR?

ASEGURAR QUE LAS PÁGINAS WEB PUEDAN SER PROCESADAS

El objetivo principal es evitar errores en el código que causen problemas a los productos de apoyo cuando traten de procesar el contenido.

Para evitar estos problemas no es imprescindible que el código sea válido según la gramática formal usada, o que cumpla al completo con la especificación. Podemos evitar la gran mayoría de errores de procesamiento si al menos la apertura y cierre de etiquetas se hace según la especificación o si los documentos están bien formados (XML).

En HTML, asegurar que la apertura y cierre de etiquetas sigue la especificación.

Esto implica que para los elementos se debe cumplir:

  • Existencia etiquetas de cierre para todos los elementos que las requieran.
  • No existencia de etiquetas de cierre para aquellos elementos en las que están prohibidas.
  • Las etiquetas de apertura y cierre se deben anidar correctamente para todos los elementos.

De igual forma, al indicar los valores de los atributos debemos hacerlo correctamente (apertura y cierre del entrecomillado)

En XHTML, asegurar que las páginas web están bien formadas.

Como XHTML es un lenguaje basado en XML, podemos usar un parseador de XML que verifique que no se producen errores al comprobar si el documento está bien formado.

En determinados lenguajes, algunos elementos y/o atributos deben tener un valor único. En caso contrario, al procesar el contenido los resultados pueden ser inconsistentes. Si los valores de los atributos id no son únicos se imposibilita la identificación del contenido de forma unívoca. Esto es especialmente problemático cuando se establecen relaciones entre el contenido y las referencias apuntan a identificadores repetidos. Por ejemplo, al relacionar etiquetas y campos de formulario o las celdas de datos y celdas de encabezado en las tablas de datos.

De igual forma, las referencias a identificadores inexistentes también es problemática. Por ejemplo, un <label> que en su atributo for haga referencia a un campo de formulario que no existe, o una celda de datos que en su atributo headers indique encabezados inexistentes.

Otros atributos como accesskey también deben tener valores únicos.

Si estos atributos no son únicos, o las relaciones establecidas entre el contenido son incorrectas o ambiguas, los agentes de usuario y productos de apoyo serán incapaces de procesar el contenido correctamente.

VALIDAR LAS PÁGINAS WEB

Si cumplimos la técnica anterior ya nos aseguramos el cumplimiento del criterio de conformidad. No obstante, aunque no sea estrictamente necesario, otra forma de cumplir este criterio de conformidad es validando el código según la gramática formal usada.

La principal ventaja de validar el código es la eliminación de las ambigüedades que se pueden producir por el uso de código incorrecto.

El uso de código (X)HTML que no valide frente a una gramática formal presenta una serie de limitaciones y desventajas:

Limitación en la compatibilidad del código. Las gramáticas del W3C nos aseguran que el código es estándar y que, por lo tanto, va a ser compatible con todos los navegadores.

Si empleamos código sin validar podemos usar elementos o atributos propietarios de los diferentes navegadores que, o bien no funcionen en el resto, o bien con el tiempo acaben desapareciendo y dejen de soportarse, ya que los navegadores tienden a cumplir los estándares.

Inseguridad sobre la compatibilidad futura. Además de los elementos propietarios, en la evolución de HTML hay una serie de elementos y atributos que antes formaban parte de la especificación pero que, actualmente, están desaconsejados. Muchos de los navegadores no soportarán esos elementos en un futuro más o menos cercano.

Falta de separación entre contenido y presentación. En el lenguaje HTML existen etiquetas que sirven para definir la estructura del documento, organizar su contenido y definir su presentación. Con frecuencia creamos código en el que se mezcla el contenido de las páginas con su presentación, generando un código complejo y difícil de mantener y modificar. En las gramáticas de tipo estricto (Strict) se evitan elementos y atributos desaconsejados, generalmente de presentación.

Las gramáticas formales publicadas para HTML 4.01 y XHTML 1.0, y sus correspondientes declaraciones de tipo de documento (DTD) son las siguientes:

HTML "strict". Da prioridad a la estructura frente a la presentación. Permite crear un código limpio de elementos desaconsejados (deprecated) y de presentación.

HTML "Transitional". Con menos restricciones que HTML "strict" permite incluir elementos de presentación, así como otros desaconsejados.

HTML "Frameset". Esta versión es igual que la "transitional" pero permite el uso de marcos.

XHTML "strict". Esta versión de XHTML contiene un elevado número de restricciones sobre los elementos, atributos, y anidamientos posibles de etiquetas. No permite la utilización de elementos de presentación.

XHTML "Transitional". Esta opción es más flexible y menos restrictiva que la versión "strict". En este caso sí permite el uso de elementos de presentación.

XHTML "Frameset". Similar a la versión transitional pero posibilita el uso de marcos.

Teniendo esto en cuenta, recomendamos usar gramáticas formales modernas como XHTML. Sin embargo, en ocasiones es necesario llegar a un compromiso entre esta recomendación y la compatibilidad con desarrollos anteriores.

Algo parecido ocurre a la hora de escoger entre el uso de un DTD "strict" o uno menos restrictivo, como el "transitional" o "loose". Recomendamos que para el desarrollo de nuevos portales se use el DTD "strict". El DTD "frameset" sólo se debería emplear en caso de que se usen marcos, aunque es importante recordar que el W3C desaconseja el uso de marcos y, por tanto, del DTD "frameset".

Es importante tener en cuenta que la validación no comprueba la semántica del documento. Es decir, comprueba que el código es correcto sintáctica y gramaticalmente (apertura y cierre de etiquetas, atributos y valores correctos, etc.) pero no comprueba que los elementos se estén usando para lo que fueron definidos. Por ejemplo, la validación no detecta si un elemento <blockquote> se está usando correctamente para marcar una cita de bloque o si, por el contrario, se está usando sólo con fines presentacionales para generar una indentación del texto.

En términos estrictos no es necesario que el código valide para cumplir este criterio de conformidad, pero sí resulta la mejor forma para asegurarnos su cumplimiento. No se trata de una condición necesaria pero sí suficiente y es la más fácil de comprobar al poder usar los validadores existentes para verificar la validez del código.

USAR EL LENGUAJE DE ACUERDO A LA ESPECIFICACIÓN

Esta se trata de otra técnica suficiente pero no necesaria. Es aún más restrictiva que las anteriores y si el código valida correctamente ya estamos cumpliendo el criterio de conformidad y esta técnica no sería necesaria.

Sin embargo, desde el punto de vista del cumplimiento de los estándares, es la técnica más completa y, por tanto, la más recomendable.

Las especificaciones definen la finalidad, significado y forma correcta de uso de las características de la tecnología correspondiente. Usar los lenguajes de marcado de acuerdo a la especificación asegura que los agentes de usuario y productos de apoyo podrán presentar, interpretar e interactuar con el contenido de forma correcta.

Esta técnica no implica sólo la validación según la gramática usada, ya que la validación únicamente comprueba la corrección sintáctica. Lo que nos está pidiendo es cumplir totalmente con la especificación, tanto gramatical, sintáctica y semánticamente. Es decir, usar los elementos correctamente con la finalidad que les corresponde.

Actualmente las gramáticas (X)HTML más soportadas son:

  • HTML 4.01: última versión madura de HTML y ampliamente soportada por los agentes de usuario y productos de apoyo.
  • XHTML 1.0: con las mismas característica de HTML pero con estructura de XML y una sintaxis más estricta. Actualmente, las versiones más recientes de XHTML no están totalmente soportadas.

¿Qué implica realmente usar (X)HTML de acuerdo a la especificación?:

  • Usar únicamente características definidas en la especificación: Por ejemplo, no usar elementos y atributos propietarios (con nulo, escaso o diferente soporte por agentes de usuario y productos de apoyo)
  • Asegurar que el contenido se pueda procesar: Debemos asegurarnos que se pueda procesar para que se interprete y muestre de forma correcta. Esto implica un marcado correcto, apertura y cierre correctos de etiquetas y atributos, así como una adecuada anidación de elementos.
  • Usar las características según se indica en la especificación: Es decir, usar los elementos según la función y significado que se indica en la especificación. Por ejemplo, no usar elementos semánticos y/o estructurales con fines presentacionales, como puede ser usar <blockquote> incorrectamente para indentar texto en vez de para su verdadera finalidad: marcar citas largas.

Como vemos, las dos primeras condiciones se comprueban automáticamente con la validación. Sin embargo, la tercera opción es algo que debemos verificar manualmente para asegurarnos que se realiza de forma correcta.

4.1.2

Para todos los componentes de la interfaz de usuario (incluyendo pero no limitado a: elementos de formulario, enlaces y componentes generados por scripts), el nombre y la función pueden ser determinados por software; los estados, propiedades y valores que pueden ser asignados por el usuario pueden ser especificados por software; y los cambios en estos elementos se encuentran disponibles para su consulta por las aplicaciones de usuario, incluyendo las ayudas técnicas.

Nota: Este criterio de conformidad se dirige principalmente a los autores web que desarrollan o programan sus propios componentes de interfaz de usuario. Por ejemplo, los controles estándar de HTML satisfacen automáticamente este criterio cuando se emplean de acuerdo con su especificación.

OBJETIVO:

Asegurar que los productos de apoyo puedan obtener información, interactuar y estar al corriente del estado de los controles de interfaz de usuario Cuando decimos que el contenido debe poder determinarse por software nos referimos a que los agentes de usuario y productos de apoyo deben poder comprenderlo e interactuar con el mismo. De esta forma, los usuarios también podrán comprender el contenido e interactuar con él a través de los productos de apoyo.

Ya hemos visto en otros principios cómo conseguir que la estructura y la semántica del contenido sea determinable por software. Por ejemplo, usando los elementos y atributos necesarios para identificar los encabezados, párrafos, listas, celdas de encabezado, texto enfatizado, citas, abreviaturas, etc. En resumen, marcar la estructura y semántica del contenido con los elementos estructurales y semánticos adecuados que nos proporciona la tecnología usada. Así, en (X)HTML usaremos <h1> - <h6> para encabezados; <ul>, <ol> o <dl> para listas; etc.

Sin embargo, cuando se trata de los controles o componentes de interacción no es suficiente indicar sólo qué son. Para poder interactuar con ellos a través de los productos de apoyo es necesario que estos sean capaces de obtener información adicional:

FUNCIÓN (rol):

Indica la funcionalidad de un componente de interacción.

Los productos de apoyo tienen que poder reconocer cual es la función del componente de interacción para transmitirla a los usuarios. En (X)HTML, cuando un lector de pantalla encuentra un enlace avisa a los usuarios diciendo la palabra "enlace" y si encuentra un <input type="text"> avisa diciendo "campo de edición de texto" o un mensaje similar. Si el lector no es capaz de determinar la función del componente de interacción, entonces tampoco será capaz de transmitirla a los usuarios y dicho elemento será inaccesible.

NOMBRE:

Texto a través del cuál se identifica un componente de interacción.

Los productos de apoyo tienen que poder reconocer cuál es el nombre del componente para transmitirlo a los usuarios. En (X)HTML, el nombre de un enlace será su texto, en un campo de formulario será el contenido de su etiqueta <label> o del atributo title, etc. Por este motivo algunos requisitos de accesibilidad obligan a proporcionar nombres significativos (textos de los enlaces, etiquetas, etc.) para que los usuarios puedan reconocerlos.

VALOR:

Propiedades, valores y estados de los componentes de interacción.

Los productos de apoyo tienen que poder reconocer cuál es el valor (si lo tienen) de los componentes de interacción para transmitírselo a los usuarios y operar con él. Por ejemplo, en (X)HTML el valor de un enlace es su atributo href y el valor de un <textarea> será el texto que contiene. Por otra parte, algunos elementos de interacción pueden tener varios estados. Por ejemplo, los botones de radio pueden estar seleccionados o no estarlo. Lo mismo ocurre con las casillas de verificación. Los productos de apoyo tienen que poder reconocer tanto los valores como los estados (determinar por software) de los elementos de interacción para transmitírselos a los usuarios.

De igual forma, las propiedades, valores y estados que pueden ser asignados por los usuarios tienen que poder ser especificados por software. Es decir, si el usuario tiene la posibilidad de cambiar el valor o el estado de los componentes de interacción, tiene que poder hacerlo también por medio de un producto de apoyo. Así, por ejemplo, un usuario podrá escribir en un campo de edición o cambiar el estado de un botón de radio o una casilla de verificación interactuando "a través" de un lector de pantalla.

Finalmente, cuando se producen cambios en los elementos de interacción, como cambios en sus valores o estados, los avisos sobre estos cambios deben estar disponibles para los agentes de usuario, incluyendo los productos de apoyo. Por ejemplo, uno de los estados más importantes de los elementos de interacción es el foco, si lo tiene o no. El estado del foco de un componente de interacción tiene que poder determinarse por software, y los avisos sobre los cambios del foco se tienen que enviar a los agentes de usuario y productos de apoyo.

Toda esta comunicación se realiza a través de la API de accesibilidad (dependiente del sistema operativo y/o tecnología usada) por medio de funciones y mensajes entre los componentes de interacción y los agentes de usuario y productos de apoyo.

Los agentes de usuario mapean los componentes de interacción a la API de accesibilidad usada y los productos de apoyo (p. ej. los lectores de pantalla) usan la API para obtener la información de accesibilidad que necesitan (función, nombre, estado o valor) y transmiten esa información a los usuarios. De igual forma, los usuarios pueden interactuar con los controles para modificar su valor o estado a través del producto de apoyo y la API de accesibilidad. Todo este proceso resulta transparente a los usuarios.

Para poder llevar a cabo todo este proceso de comunicación es necesario que los componentes de interacción se creen con una tecnología compatible con la accesibilidad. Nuestra responsabilidad como desarrolladores dependerá de si usamos controles estándar de acuerdo a la especificación o, por el contrario, modificamos o programamos nuestros propios componentes de interacción.

Si usamos tecnologías accesibles, componentes de interacción estándar y siguiendo la especificación (por ejemplo, usando XHTML estándar) este proceso es directo. Es decir, los productos de apoyo serán capaces de obtener la información necesaria, interactuar y estar al corriente del estado de los controles usados sin que tengamos que adoptar medidas adicionales.

Sin embargo, si usamos controles personalizados mediante scripts u otras tecnologías, bien modificando los controles estándar existentes o creando controles propios, entonces debemos adoptar medidas adicionales para asegurar la compatibilidad con los productos de apoyo. Es decir, debemos asegurarnos de forma activa que los productos de apoyo serán capaces de reconocer el nombre, función, valor y estado de los componentes de interacción usados. De igual forma, los usuarios deben poder interactuar con ellos para modificar su estado o su valor y se les debe informar sobre los cambios que se produzcan en dicho estado o valor.

¿CÓMO CUMPLIR?

Las medidas de accesibilidad o técnicas que podemos usar para cumplir este criterio de conformidad dependerán de cómo implementemos los componentes de interacción. Consideramos las siguientes situaciones que se nos pueden plantear:

  • Uso de componentes de interacción estándar.
  • Uso de scripts para modificar un componente de interacción estándar.
  • Uso de componentes de interacción en una tecnología de programación.
  • Creación de componentes de interacción propios con un lenguaje de programación.

A continuación explicaremos cómo cumplir el criterio de conformidad según la situación en la que nos encontremos.

SI USAMOS COMPONENTES DE INTERACCIÓN ESTÁNDAR

En el caso de que usemos componentes de interacción estándar como, por ejemplo, los componentes disponibles en (X)HTML, entonces tenemos que usar las características del lenguaje para indicar el "nombre", "función" y "valor".

En general, si usamos tecnologías accesibles, se trata de usar los componentes de interacción estándar que proporcionen dichas tecnologías de acuerdo a su especificación o documentación disponible. Estos componentes, si están debidamente diseñados, serán capaces de transmitir estas propiedades a los productos de apoyo, permitir a los usuarios modificar aquellas propiedades configurables (por ejemplo, su valor o estado) e informar sobre los cambios que se produzcan (p. ej. cambios en los valores, estados o situación del foco).

Sin embargo, nuestra responsabilidad como desarrolladores pasa además por establecer los valores de algunas de esas propiedades. Por ejemplo, en (X)HTML, dando un nombre a un campo de formulario mediante el elemento <label> o creando textos para los enlaces que identifiquen su destino, etc.

Por tanto, para (X)HTML debemos cumplir lo siguiente:

Usar enlaces y controles de formulario HTML

Usando de forma adecuada los enlaces y controles estándar de (X)HTML aseguramos la interacción con el teclado y los productos de apoyo.

Por ejemplo, cuando un lector de pantalla encuentra un enlace estándar, lo reconoce como elemento de interacción e informa a los usuarios de su presencia (por ejemplo, diciendo "enlace"). Esto es porque los enlaces estándar tienen asignada una función ("enlace") definida y reconocida por los agentes de usuario y productos de apoyo. Una vez reconocida su función informan al usuario sobre su nombre, en este caso el texto del enlace.

Así, por ejemplo, las propiedades de los enlaces (X)HTML estándar son:

Función o Rol: "enlace".

Nombre: el texto del enlace, el contenido del atributo 'title' y/o el contenido del atributo 'alt' si existe una imagen dentro del enlace.

Valor: contenido del atributo 'href'.

ejemplo de código para un link

Valor y nombre aplicados a un elemento <a>

Otro ejemplo que sirve para entender estos conceptos puede ser el de un control de formulario de tipo "radio". Un lector de pantalla reconoce su presencia y su función (botón de radio), así como su nombre (su <label> o 'title') y su estado (seleccionado o no seleccionado) permitiendo a los usuarios interactuar con él y cambiar dicho estado.

Propiedades de un control de formulario (X)HTML de tipo radio:

Función o Rol: "botón de radio"

Nombre: contenido del elemento <label> o el contenido del atributo 'title'

Estado: contenido del atributo 'checked'

ejemplo de código para un formulario

Rol, nombre y estado de una casilla de verificación en (X)HTML

En la siguiente tabla se resume cómo se determina la función, nombre, valor y estado a partir de enlaces y controles de formulario (X)HTML.

tabla de relaciones

Tabla de referencia

Como comentamos antes, al usar estos controles (X)HTML estándar y de forma adecuada aseguramos la correcta interacción entre estos y los productos de apoyo. Nuestra responsabilidad como desarrolladores es proporcionar los valores de aquellas propiedades de accesibilidad que sea necesario establecer y no se proporcionan de forma automática (un nombre significativo). Por ejemplo, el texto de los enlaces o las etiquetas para los controles de formulario.

Usar el elemento <label> para asociar las etiquetas a los controles de formulario o, en su defecto, el atributo 'title'

Se trata, simplemente, de proporcionar un texto que informe a los usuarios sobre la finalidad del control de formulario. Este texto lo proporcionaremos mediante el elemento <label> o, cuando éste no se pueda usar, mediante el atributo 'title' del control de formulario.

Este texto es el que se transmitirá a los productos de apoyo para indicarles el nombre del control de formulario.

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 con el que se quiere asociar. 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"

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 mostrar una etiqueta pueda 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.

Usar el atributo 'title' en marcos y marcos en línea

De igual forma que para otros elementos de (X)HTML, para proporcionar un nombre descriptivo para los marcos y marcos en línea (en caso de que los usemos), es necesario usar el atributo 'title'.

Con el atributo 'title' describiremos de forma escueta la finalidad o contenido de los marcos. El título sirve a los usuarios para decidir si les interesa o no su contenido sin tener que visitarlos.

Usar HTML de acuerdo a la especificación

Las especificaciones definen la finalidad, significado y forma correcta de uso de las características de la tecnología correspondiente. Usar los lenguajes de marcado de acuerdo a la especificación asegura que los agentes de usuario y productos de apoyo podrán presentar, interpretar e interactuar con el contenido de forma correcta.

Usar HTML de acuerdo a la especificación implica:
  • Usar únicamente características definidas en la especificación: Por ejemplo, no usar elementos y atributos propietarios (con nulo, escaso o diferente soporte por agentes de usuario y productos de apoyo).
  • Asegurar que el contenido se pueda parsear: Debemos asegurarnos que se pueda parsear para que se interprete y muestre de forma correcta. Esto implica un marcado correcto, apertura y cierre de etiquetas y anidación de elementos adecuada, atributos y valores correctos, etc.
  • Usar las características según se indica en la especificación: Es decir, usar los elementos según la función y significado indicados en la especificación. Por ejemplo, no usar elementos semánticos y/o estructurales con fines presentacionales. Un error sería usar <fieldset> para crear cajas donde agrupar contenido general, en vez de usarlo para agrupar semánticamente controles de formulario.

Usar funciones DOM para añadir contenidos a la página

En caso de que los scripts estén dentro de las tecnologías usadas compatibles con la accesibilidad y los usemos para generar contenido mediante controles de interfaz de usuario (por ejemplo, para avisar sobre problemas encontrados en la validación de formularios), debemos usar DOM scripting en vez de versiones propietarias e intrusivas del lenguaje. De esta forma aumentamos su compatibilidad con los agentes de usuario y productos de apoyo.

Además, tal y como ya se ha visto anteriormente en el curso (criterios de conformidad 1.3.2 – Secuencias significativas y 2.4.3 - Orden del foco), debemos usarlo correctamente. Es decir, al incluir contenido debemos hacerlo en el lugar y de la forma adecuada para que se mantenga un correcto orden de lectura y de tabulación, asegurando la interoperabilidad e independencia de dispositivo. Para ello, insertaremos el contenido generado dinámicamente en el DOM justo a continuación del elemento que lo lanza.

SI USAMOS SCRIPTS PARA MODIFICAR UN COMPONENTE DE INTERACCIÓN ESTÁNDAR

En ocasiones se usan scripts para modificar el comportamiento habitual de los componentes de interacción estándar, añadiendo funcionalidades especiales a los formularios. Por ejemplo, mostrar u ocultar campos dependientes unos de otros mediante menús de selección, incorporar validación de cliente antes del envío de los formularios mostrando en la página los errores detectados, actualizar dinámicamente los valores de algunos controles dependiendo del valor de otros, etc.

En todos estos casos también debemos usar funciones DOM para añadir y/o modificar el contenido de la página.

Si usamos componentes de interacción en una tecnología de programación

Al igual que ocurre con (X)HTML, existen tecnologías que son compatibles con la accesibilidad usando para ello la API de accesibilidad del sistema o bien APIs propias. Cuando usemos componentes de interacción estándar en alguna tecnología de programación (como puede ser Flash o Java), e incluyamos éstas dentro del conjunto de tecnologías compatibles con la accesibilidad, debemos hacerlo usando correctamente las características de accesibilidad propias de estas tecnologías.

Por ejemplo, la accesibilidad en los objetos Flash está soportada a través de Microsoft Active Accessibility (MSAA). MSAA es una tecnología de Microsoft que proporciona un mecanismo de comunicación entre las aplicaciones de Windows y los productos de apoyo. Permite definir la información de accesibilidad de las aplicaciones y sus componentes de interacción y mostrar dicha información a los productos de apoyo, como lectores de pantalla.

En el caso de la tecnología Java (por ejemplo, para crear un applet) debemos emplear la API de Accesibilidad de Java, JAAPI (Java Accessibility API). Para emplear esa API, los componentes que usemos deben implementar el interfaz Accesible. Al usar este interfaz se pueden hacer llamadas a métodos y asignar las propiedades necesarias para proporcionar la información y funcionalidad necesaria para habilitar su accesibilidad. Entre el conjunto de las propiedades que se pueden asignar mediante este interfaz se encuentran, entre otras cosas, una descripción de su función (rol) (si se trata de un botón, una casilla de verificación, etc.), su nombre (descripción de su finalidad), su estado o valor. De igual forma, también existen eventos que notifican sobre los cambios producidos en los componentes (por ejemplo, cuando cambia su estado o valor).

En resumen, al usar tecnologías de programación compatibles con la accesibilidad lo haremos usando sus componentes de interacción estándar y las características de accesibilidad de la API de dichas tecnologías.

SI CREAMOS COMPONENTES DE INTERACCIÓN PROPIOS CON UN LENGUAJE DE PROGRAMACIÓN

Al usar tecnologías de programación accesibles para crear controles de interfaz de usuario podemos hacerlo usando los controles estándar, que ya están programados para funcionar con las APIs de accesibilidad, proporcionándole las propiedades (nombre, función, etc.) de forma que estos controles ya serán accesibles para los productos de apoyo.

Sin embargo, también podemos crear y programar nuestros propios controles sin usar los controles estándar ya disponibles en la tecnología empleada. En ese caso, usaremos una tecnología que soporte las características de accesibilidad de las APIs de las plataformas en las que se usarán los agentes de usuario, implementando los componentes de interacción respetando la API de accesibilidad correspondiente y asegurándonos de proporcionar las características de accesibilidad necesarias.

Aplicaciones Ricas de Internet Accesibles

Con la aparición y evolución de las aplicaciones web, el grupo de componentes de interacción estándar de (X)HTML resulta limitado para lograr interfaces de usuario complejas similares a las aplicaciones de escritorio (vistas en árbol, sliders o controles deslizantes, etc.). Esto es debido a que HTML no se diseñó para crear aplicaciones web. Para sortear esta limitación, los desarrolladores han ido creando nuevos componentes personalizados que cubriesen sus necesidades.

Estos componentes personalizados se crean a partir de los controles estándar de (X)HTML (enlaces y controles de formulario) junto con otros elementos estáticos (como gráficos e imágenes, <div>, <span>, <td>, etc.) a los que se les añade una nueva capa de comportamiento mediante tecnologías como JavaScript para emular la funcionalidad de los componentes de interacción de escritorio u otros componentes complejos.

La finalidad de los nuevos componentes no es únicamente parecerse a los controles de aplicaciones de escritorio, sino mejorar también la experiencia de los usuarios. En las páginas web normales cada vez que se piden datos al servidor es necesario recargar toda la página. Esto entorpece la interacción en aplicaciones complejas donde a veces es necesario solicitar datos al servidor al usar determinados controles. Para evitar estas interrupciones en la actividad de los usuarios se usan técnicas como Ajax para realizar las peticiones de datos al servidor en segundo plano, de forma transparente a los usuarios, y actualizar la información de la página. De esta forma se puede usar una aplicación web compleja, con diferentes controles y múltiples peticiones al servidor, sin que sea necesario recargar por completo la página, asemejándose así al comportamiento de las aplicaciones de escritorio.

Problemas de accesibilidad

Para que todos estos nuevos componentes de interacción sean accesibles para las personas con discapacidad, los productos de apoyo tienen que poder interactuar con los mismos. Sin embargo, la información de accesibilidad que necesitan los productos de apoyo no está disponible si estos controles se implementan únicamente con las tecnologías web actuales, como (X)HTML, JavaScript y/o Ajax, sin aplicar medidas adicionales.

Los productos de apoyo no saben cuál es la FUNCIÓN del componente, qué es lo que hace.

Por ejemplo, imaginemos un control deslizante (slider) que permita especificar múltiples valores. Este control no existe en (X)HTML y por lo tanto es necesario programarlo. Para ello, el nuevo control se puede basar en un control existente al que se le añade una nueva capa de comportamiento mediante JavaScript. Una posibilidad es usar un botón estándar que al pulsar sobre él se detecte el desplazamiento del ratón y en función de este desplazamiento se asigne un valor u otro.

#

Control deslizante personalizado para manejar el volumen.

La nueva presentación visual de este componente se lograría también mediante una combinación de JavaScript y hojas de estilo. Así, en el código (X)HTML sólo tendríamos una etiqueta y un botón.

#

Botón de envío en el que se basa el control deslizante para manejar el volumen.

Los usuarios de lectores de pantalla únicamente sabrán que se trata de un "botón de envío", ya que esa es la función del control estándar en el que se basa el nuevo componente de interacción. Si está bien etiquetado ("Volumen") sabrán que se trata de un botón para controlar el volumen, pero no podrán saber cuál es realmente la función y forma de uso del nuevo control ("slider" o "control deslizante")

Los productos de apoyo no saben cuál es el ESTADO actual del componente.

Si el componente tiene determinadas propiedades que varían de forma dinámica, según se interactúe con los mismos, los productos de apoyo y los usuarios no sabrán cuál es el valor actual de estas propiedades.

Siguiendo con el ejemplo del control deslizante, los usuarios de lectores de pantalla no pueden saber cuál es el valor actual del control al manejarlo, ya que el botón en el que se basa no tiene estados en HTML.

¿El volumen está al 20% o al 80%?

Los productos de apoyo no sabrán el VALOR de otras importantes propiedades del componente.

El valor de otras propiedades tampoco está disponible para los productos de apoyo. Por ejemplo, en el control de volumen no saben cuáles son los valores mínimos y máximos que se pueden asignar con el control, ya que el elemento <button> en el que se basa no dispone de estas propiedades.

Los productos de apoyo no serán conscientes de las ACTUALIZACIONES del contenido.

Cuando el uso de un control implica un cambio en el contenido de la página, estas actualizaciones no suelen ser percibidas por los usuarios de productos de apoyo. Mediante AJAX se puede actualizar el contenido de la página, o parte del mismo, mediante consultas al servidor en segundo plano de forma asíncrona. Estos cambios en el contenido no suelen ser percibidos por los productos de apoyo y, en el caso de que sí lo fuesen, los usuarios podrían no darse cuenta de que se ha actualizado el contenido o cómo localizar el nuevo contenido.

Un control deslizante como el del ejemplo puede usarse también para desplazarse por una galería de imágenes. Según desplacemos el control cambiará la imagen visualizada en primer plano en ese momento.

Es decir, se está produciendo un cambio en el contenido de la página a consecuencia del desplazamiento del control. Tanto los productos de apoyo (p. ej. lectores de pantalla) como los usuarios no serán conscientes de dicha actualización ya que lo que ellos perciben que están manejando es un simple “botón de envío”.

Lo mismo ocurriría si el control se usase para introducir un porcentaje para realizar cálculos sobre determinados valores (impuestos, intereses, etc.) y hubiese datos dependientes del valor introducido en el control que se actualizan con el mismo. Los usuarios podrían no ser conscientes de que se está actualizando dicho valor.

Navegación mediante el TECLADO limitada.

La navegación mediante teclado se puede ver limitada o impedida por varios motivos:

  • Los componentes se puede implementar usando elementos estáticos de (X)HTML. Por ejemplo, se puede añadir funcionalidad a gráficos o imágenes (<img>), encabezados o celdas de tablas (<th> y <td>), o incluso a contenedores como <div>, entre otros. Todos estos elementos estáticos de (X)HTML no pueden recibir el foco y, por tanto, son inaccesibles mediante teclado.
  • Si los componentes se implementan usando controles estándar de (X)HTML sí pueden recibir el foco. Sin embargo, si se modifica la forma natural de interacción con los mismos es posible que tampoco se puedan operar mediante teclado. Por ejemplo, un control deslizante implementado con un botón (<button>) se maneja pulsando sobre él y “desplazándolo” con el ratón. A pesar de ser accesible con teclado, la forma de interacción del control estándar usado es simplemente pulsando sobre él y no desplazándolo. Los usuarios de teclado no podrán manejarlo correctamente mediante el tabulador. Incluso en el caso de que se implemente un mecanismo de uso mediante el teclado, como las teclas de dirección, los usuarios podrían no ser conscientes de esta posibilidad ya que perciben el componente como un “botón de envío” (su función por defecto) y no esperan un comportamiento diferente.

WAI-ARIA

La especificación WAI-ARIA (WAI - Accessible Rich Internet Applications, Aplicaciones Ricas de Internet Accesibles de la Iniciativa de Accesibilidad Web) trata de solucionar los problemas de accesibilidad relacionados con el uso de contenidos dinámicos e interfaces de usuario avanzadas realizadas en Ajax, Javascript, HTML y tecnologías relacionadas.

El objetivo de WAI-ARIA es solucionar estos problemas de accesibilidad sin renunciar a las ventajas y funcionalidades de este tipo de aplicaciones. Es decir, no se trata de impedir o prohibir su uso, sino de aportar soluciones que permitan crear aplicaciones ricas de Internet accesibles.

Para ello, se definen mecanismos para transmitir a los productos de apoyo la información sobre la función, los estados y las propiedades (y sus valores) de los componentes de interacción personalizados, así como las notificaciones sobre los cambios producidos en los mismos. Del mismo modo, también se establecen medios y estrategias para hacer estas aplicaciones independientes de dispositivo.

WAI-ARIA permite establecer atributos a los elementos para identificar características de los componentes de interacción, la forma en la que se relacionan entre sí y sus estados

El conjunto de documentos que el W3C proporciona sobre WAI-ARIA son los siguientes:

* WAI-ARIA, especificación técnica [http://www.w3.org/TR/wai-aria/]:

Recomendación W3C de Estándar Web, en estado de borrador de trabajo.

Destinada a desarrolladores de navegadores web, productos de apoyo y otros agentes de usuario; desarrolladores de tecnologías web; y desarrolladores de herramientas de evaluación de accesibilidad.

* WAI-ARIA Primer [http://www.w3.org/TR/wai-aria-primer/]: Nota del Grupo de Trabajo del W3C. Se trata de una introducción a WAI-ARIA explicando los problemas de accesibilidad que trata de resolver y los conceptos fundamentales.

* WAI-ARIA Authoring Practices [http://www.w3.org/TR/wai-aria-practices/]: Nota del Grupo de Trabajo del W3C. Destinada a los desarrolladores de contenido web, describe cómo desarrollar aplicaciones enriquecidas de Internet usando WAI-ARIA.

* WAI-ARIA User Agent Implementation Guide [http://www.w3.org/TR/wai-ariaimplementation/]: Nota del Grupo de Trabajo del W3C. Describe cómo deben dar soporte a WAI-ARIA los navegadores y otros agentes de usuario. De forma específica, cómo deben transmitir las características de WAI-ARIA a las API de accesibilidad de la plataforma.

* WAI-ARIA Roadmap [http://www.w3.org/TR/wai-aria-roadmap/]: Nota del Grupo de Trabajo del W3C. Describe el camino a seguir para hacer accesibles las aplicaciones ricas de Internet, indicando los pasos ya realizados, los pasos pendientes y la temporalización de los mismos.

Además de esta documentación oficial, existe documentación adicional en Internet sobre WAI-ARIA útil para comprender los conceptos fundamentales y ver ejemplos de funcionamiento:

  • Introducción a WAI-ARIA [http://www.areia.info/introduccion-a-wai-aria/]: traducción al español del artículo original publicado por Gez Lemon en la comunidad de desarrolladores de Opera.
  • Ejemplo de slider ARIA [http://www.paciellogroup.com/blog/?p=68]: ejemplo de implementación de un control deslizante (slider) en WAI-ARIA, por Hans Hillen en el Blog de Paciello Group
  • Ejemplo de checkbox de tres estados [http://www.paciellogroup.com/blog/?p=53]: ejemplo de implementación de una casilla de verificación (checkbox) de tres estados, por Steve Faulkner en el Blog de Paciello Group