Usable y accesible

Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas

2012-03-28T00:21:00.008+02:00

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

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

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

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

Ver la página de ejemplo

Descargar el ejemplo (RAR, 13Kb)

La descarga y uso del ejemplo es completamente libre, pero os agradecería mucho que compartierais mejoras que se os ocurran o problemas que detectéis.

He probado su funcionamiento con NVDA, Explorer 7, Explorer 8, Explorer 9, Firefox 1.5, Firefox 2, Firefox 3, Firefox 11, Chrome 17, Opera 11, Safari 5 (para Windows) y desde una BlackBerry y una iPad. En Explorer 6 no hay problema para visualizar la descripción, pero se ve siempre presente como si el javascript estuviera deshabilitado.

HTML

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


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"  >
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="es" lang="es">
<head>
<title>Ejemplo descripción extensa accesible de imágenes< /title >
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta name="author" content="Olga Carreras" />
<meta name="description" content="Descripciones extensas de imágenes accesibles con lectores de pantalla y sin imágenes activas" />

<link href="estilos.css" type="text/css" rel="stylesheet" media="all" />
<script type="text/javascript" src="utils.js"></script>
</head>

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

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


<body>
<h1>Ejemplo de descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas</h1>
<p>Olga Carreras. Ejemplo del artículo <a href="http://olgacarreras.blogspot.com">"Descripción extensa de una imagen: accesible con lector de pantalla y sin imágenes activas"</a></p>

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


<div>
<img src="razones_uso_tecnologia_accesible.gif" alt="Razones de uso de la tecnología accesible" id="image1" class="images" />
<p><a href="#descripcion" title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible" id="linkDescripcion" class="oculto">Ver descripción de la imagen</a></p>
</div>

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

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

Ese enlace no es necesario puesto que si la imagen no está cargada se verá la descripción detallada y los lectores de pantalla no van a tener problemas para acceder a dicha descripción.

Sin embargo, puede darse el caso de usuarios con vista cansada o que accedan desde un dispositivo móvil y el tamaño de letra de la imagen les resulte pequeño (y no sepan o no puedan hacer zoom de la imagen)

En ese caso les puede ser de utilidad pulsar el enlace para ver la descripción.

El enlace es un ancla al comienzo de la descripción, después veremos que mediante javascript no intrusivo se le ha asignado una función que permite mostrar/ocultar la descripción detallada y personalizar el texto y el TITLE del enlace en función de si se visualiza o no la descripción.


<div id="descripcion" class="visible">
<h2>< < Descripción de la imagen: Razones de uso de la tecnología accesible</h2>
<h3>Por entorno laboral</h3>
<ul>
<li>Con discapacidad severa: 4%</li>
<li<Con discapacidad moderada: 3%</li>
<li<Sin discapacidad: 6%</li>
</ul>
[el resto de la descripción larga, no la pongo aquí toda]
</div>

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

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

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


<div class="pie">
<p>Probad a deshabilitar javascript, css o imágenes. Para ver sin imágenes cargadas o sin javascript activo acordaros de recargar la página una vez que los desactivéis.</p>
<p>Para facilitaros verla sin la imagen cargada os dejo una copia de la misma página pero donde se ha escrito mal el nombre de la imagen y por tanto no la encuentra: <a href="descripcion_imagenes_accesibles_sinimg.html">Probar esta página cuando no se encuentra la imagen.</a></p>
</div>
</body>
</html>

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

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

Me parece importante destacar que se ha separado:

el contenido: eso es únicamente lo que vemos en la página HTML
la presentación: no se especifica ningún estilo en la página, todos están recogidos en la CSS
el código javascript: no hay ningún evento, ninguna función, nada que haga sospechar que esta página incluye javascript (salvo la llamada al JS en el HEAD). Todo el javascript, incluso las funciones que se llaman en el onLoad de la página, están definidas de forma no intrusiva.

CSS

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


.oculto{
position:absolute;
left:-999em;
}

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

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

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

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


.images{
width:auto;
height:auto;
}
.widthImage1{
width:393px;
height:363px;
}

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

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

JS


function addLoadEvent(func) {
var oldonload = window.onload;
if (typeof window.onload != 'function') {
window.onload = func;
} else {
window.onload = function() {
if (oldonload) {
oldonload();
}
func();
}
}
}

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

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


var Image1Width=393;
function noimage(){
var objImagen = document.getElementById('image1');
var objDescripcion = document.getElementById('descripcion');
var linkDescripcion = document.getElementById( 'linkDescripcion' );
objDescripcion.className = 'oculto';
linkDescripcion.className = 'visible';
if (objImagen.offsetWidth != Image1Width)
{
objDescripcion.className = 'visible';
objImagen.className = 'widthImage1';
linkDescripcion.className = 'oculto';
}
}

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

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

En la propuesta de S.Faulkner se comparaba si era igual a 1, pero esto no me funcionaba en todos los navegadores. Por eso lo comparo con el ancho real "393". Es más "sucio" porque no me sirve para todas las imágenes como el compararlo con 1, sino que he de personalizarlo para cada una, pero funciona en todos los navegadores.

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

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

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


addLoadEvent (function(){
var linkDescripcion = document.getElementById( 'linkDescripcion' );
var objDescripcion = document.getElementById('descripcion');
linkDescripcion.onclick = function(){
if (objDescripcion.className == 'oculto')
{
objDescripcion.className = 'visible';
linkDescripcion.innerHTML="Ocultar descripción de la imagen";
linkDescripcion.title="Ocultar la descripción de la imagen Razones de uso de la tecnología accesible"
}else{
objDescripcion.className = 'oculto';
linkDescripcion.innerHTML="Ver descripción de la imagen";
linkDescripcion.title="Mostrar la descripción de la imagen Razones de uso de la tecnología accesible"
}
}
}
)

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

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

Algo que no he hecho para que se viera más claro lo que hacían las funciones y que se debería hacer para separar el código javascript del texto concreto que queremos personalizar, sería definir esos literales en un fichero diferente de variables para que nos sean más sencillos de modificar. Así en el código sólo incluiriamos variables y no texto concreto.

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

Artículos relacionados:

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

2009-05-05T21:30:00.022+02:00

El contenido de este artículo se ha movido a la recopilación Respuesta a 25 dudas habituales sobre accesibilidad web

HIJAX

2007-10-22T14:20:00.001+02:00

Artículos relacionados
[26-05-07] AJAX accesible I
[07-09-07] AJAX accesible II: WAI-ARIA
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

El otro día me preguntaban qué era Hijax, si era la evolución de AJAX, o algo nuevo, o ¡qué era!, muy preocupado por si se estaba perdiendo algo referente a AJAX. No me voy a extender mucho, ya habló de Hijax Fran Tarifa el otro día en Hijax: ¿Ajax accesible? (aunque no estoy de acuerdo con sus conclusiones)

Hijax es una metodología a seguir a la hora de realizar aplicaciones AJAX, que consiste en aplicar a estos desarrollos la estrategia que se conoce como "mejora progresiva", propia del diseño web, para que dichos desarrollos AJAX sean accesibles.

Jeremy Keith ya hablaba de aplicar la "mejora progresiva" a AJAX en marzo de 2005, antes de que se le ocurriera bautizar a esta metodología como Hijax, en su artículo Progressive enhancement with Ajax.

Parece que esto de Hijax es nuevo, pero Jeremy no se inventó el término ayer, sino el 1 de enero de 2006 a las 7:40, en el artículo Hijax. Supongo que esa Nochevieja fue sonada para sentarse a primera hora a hablar de Hijax [bromilla].

El caso es que últimamente se oye hablar mucho de Hijax, como algo nuevo, lo cual se debe en parte a sus ponencias como "Bulletproof AJAX (Ajax a pruebas de balas)" y en parte a ese curioso boca a boca exponencial (buzz) propio de Internet.

Esto de bautizar a todo con un nombre gancho es muy habitual (AJAX, Web 2.0, etc.) y muy eficaz para estar en boca de todos (o en blog de todos, como tendríamos que decir hoy en día), pero bueno, no está mal si eso ayuda a difundir buenas prácticas. Hay que reconocerle a Jeremy Keith que lleva ya años abogando por hacer las cosas bien, es simplemente que me hace gracia como de repente todo el mundo habla de algo cotidiano y habitual como si fuera muy novedoso por tener un nombre vistoso. Él mismo ironizaba:

I’ve even got a nice shiny buzzword for this technique: Hijax. (Hijax, Jeremy Keith) [1]

Pero dime, ¿en qué consiste eso de Hijax? Pues me temo que te va a decepcionar un poco, porque no es más que aplicar aquello que venimos recomendando una y otra vez: JavaScript no intrusivo a la hora de plantear alternativas accesibles.

El resumen es el siguiente:

1. Haz que la aplicación funcione sin AJAX mediante peticiones normales al servidor que recarguen la página.

2. Ahora añade JavaScript no intrusivo para incluir el código AJAX, de este modo, si el user-agent no admite JavaScript o está desactivado, la aplicación seguirá funcionando correctamente, puesto que el código es invisible y no afecta al funcionamiento de la página.

Según dice Jeremy, la clave es: Plan for Ajax from the start. Implement Ajax at the end.

Nada nuevo, pero si llamarle Hijax ayuda a difundir las buenas prácticas de la programación AJAX, pues nada: viva Hijax! todos a aplicar Hijax! es decir, a seguir haciendo las cosas bien.

[1]

There seems to be an inherent paradox in saying that you need to think about your server-side architecture but you should just be building old-fashioned page by page submissions before hijacking them with Ajax (Hijax, Jeremy Keith)

Hijax, vendría del término "hijack", secuestrar.

Artículos relacionados
[26-05-07] AJAX accesible I
[07-09-07] AJAX accesible II: WAI-ARIA
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Enlaces que actúan como botones. Implementación accesible.

2007-09-24T16:36:00.004+02:00

A menudo nos encontramos con enlaces que actúan como botones, es decir, no enlazan con una nueva página u operativa en el "href", sino que este se deshabilita con "#", "void(0)" o "javascript:;" y se le asigna por ejemplo un "onclick" que realice una acción.

Encontramos este tipo de enlaces sustituyendo a los botones de un formulario, o aparecen en la última columna de una tabla para realizar alguna acción asociada a esa fila ("Editar", "Detalle", etc.), o en otros muchos contextos.

¿Necesitas por exigencias contra las que ya no puedes luchar que sean enlaces?... bueno, no pasa nada, pero hagámoslo bien.

Quiero hacer esto

Vamos a imaginar el siguiente ejemplo: tenemos un formulario muy simple, con un único campo "Nombre" que queremos enviar mediante un enlace "Enviar".

Su aspecto sería el siguiente:

¿Qué nos podemos encontrar?

Veamos varias variantes. NINGUNA de ellas es accesible:
1.
<a href="javascript:enviar()">Enviar</a>

2.
<a href="#" onclick="enviar()">Enviar</a>

3.
<a href="javascript:void(0)" onclick="enviar()">Enviar</a>

4.
<a href="javascript:;" onclick="enviar()">Enviar</a>

5.
<a href="javascript:;" onclick="enviar()" onkeypress="enviar()">Enviar</a>

6.
<a href="javascript:;" id="enlaceEnviar">Enviar</a>

Todas ellas llaman a la función enviar() que somete el formulario:

function enviar(){document.miform.submit()}

Salvo la versión 6, que se han molestado en implementar javascript no-intrusivo.

document.getElementById("enlaceEnviar").onclick=function (){document.miform.submit()}

¿Por qué ninguna de estas opciones es accesible?

Porque todas dependen de que el navegador del usuario admita javascript o lo tenga activo. En caso contrario no funcionará.

¿Cuál es entonces la solución?

Pues si Mahoma no va a la montaña...

¿Por qué empeñarnos en hacer enlaces que actúen como botones? ¿Por qué no hacemos botones que parezcan enlaces?

<input type="submit" name="enviar" id="enviar" value="Enviar" class="enlace" />

Este botón tendrá el mismo aspecto que nuestro enlace tan sólo con que definamos su clase "enlace" (en la CSS) de esta manera:

input.enlace{border:0; background-color:#fff; text-decoration:underline; color:#000; cursor:pointer;}

¿Por qué algo tan sencillo y limpio no se encuentra nunca?

Nota: si necesitas tener varios botones que actúen de esta manera, quizás deberías leer Formulario con varios botones. Implementación accesible.

AJAX Accesible (II): WAI-ARIA

2007-09-07T13:07:00.017+02:00

Artículos relacionados
[26-05-07] AJAX accesible I
[22-10-07] AJAX accesible III: HIJAX
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Nota 2012: cuando en el artículo se ponen ejemplos como x2:role="role:checkbox" aaa:checked="true" actualmente se marcan como role=”checkbox” aria-checked="true". Sobre la simplificación actual en la especificación de roles y atributos: Knowing when to break the rules

Por otra parte, en el artículo HTML5 y accesibilidad hablo sobre el soporte de Aria Roles por los diferentes lectores de pantalla y sobre cómo usarlos con las nuevas etiquetas semánticas de HTML5.

Cuando abordé hace unos meses el tema de AJAX Accesible nombré de pasada WAI-ARIA, sin profundizar más en el tema, puesto que me parecía suficientemente importante para abordarlo en un futuro en otro artículo diferente.

A raíz de un correo en el que se me preguntaba sobre el tema, influenciada por el hecho de que en el último mes he estado dedicada en exclusiva a desarrollos AJAX, y consciente de que hay muy poca documentación o artículos sobre el tema (y menos aún en español), me ha parecido que era un buen momento para escribir algo al respecto. Espero que le sea de utilidad al lector que me preguntaba por este tema y a cualquiera que se dejé caer por aquí. Y ya de paso, me gustaría saber si alguien está aplicándolo en la práctica.

Cuál es el problema

Pongamos un ejemplo. Nos serviría cualquiera en el cual se modificara dinámicamente una página web. Imaginemos el siguiente:

Tenemos un enlace o botón ("Ver última noticia") en nuestra página. Al pulsarlo se escribe una noticia mediante la modificación del innerHTML del div que la contiene.

Me da igual que se utilice o no AJAX, puesto que el problema es el mismo en ambos casos, pero imaginemos que recuperamos el texto de la noticia mediante AJAX.

Es sólo un ejemplo, no entraremos en si es o no usable.

Con un navegador que admita javascript, que lo tenga activo y soporte AJAX, no tendremos ningún problema: el texto de la noticia se escribirá dinámicamente.

Además hemos hecho los deberes (ver AJAX Accesible) y si el usuario trabaja con un user-agent que no admita javascript, no lo tenga activo o no soporte AJAX, no tendrá problemas, puesto que la página se recargará para mostrarle de nuevo la página con la noticia (o cualquier otra alternativa que se decida).

Podríamos pensar que nuestra página ya no presenta problemas pues hemos tenido en cuenta su accesibilidad, hemos proporcionado una alternativa, de modo que todos los usuarios puedan leer la noticia.

Y sin embargo sigue existiendo un problema de accesibilidad, puesto que hay usuarios que no podrán leer esa noticia, ¿quiénes? Haz la prueba. Eres un usuario que tienes por ejemplo Explorer (o cualquier otro navegador que soporte javascript y lo tenga activo). Pero además eres invidente y usas, por ejemplo, JAWS como lector de pantalla. Cuando pulsas "Ver última noticia" esta aparece en la página gracias a AJAX sin ningún problema, pero tú no puedes verla, ¿te lee JAWS el texto de la noticia?

La respuesta es NO.

Cuál es la solución: WAI-ARIA

WAI-ARIA (Accessible Rich Internet Applications) Suite incluye los siguientes documentos:

La hoja de ruta: Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap).
WAI-ARIA Roles (en español se ha traducido "roles" por "funciones"): Roles for Accessible Rich Internet Applications (WAI-ARIA Roles).
WAI- States (estados y propiedades): States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties).

[nota 2009: se han actualizado estos documentos]

En qué consiste la solución

Cuando hable de AT me referiré a cualquier tecnología asistiva (Assistive Technology (AT)): lectores de pantalla, software de dictado o teclados de pantalla.

Tabindex

Lo primero que necesita saber la AT es qué objeto tiene el foco.
Necesitamos que aquellos objetos que vayan a cambiar dinámicamente puedan coger el foco, para ello utilizamos tabindex="-1".

Virtually all adaptive technology solutions, such as screen readers and onscreen keyboards, need to know what object currently has focus. […] HTML 4.01 and XHTML 1.x limit script authors to only being able to provide focus to form and anchor elements yet the Document Object Model Specification allows all elements to receive events including keyboard events. This means that HTML, by design prohibits script authors from making all HTML elements keyboard accessible. This single problem has impacted the usability of Web pages whereas gaining access to all elements means using the tab key on desktop browsers. This slow, unproductive, approach makes it difficult for portal navigation whereas all active elements must be tabbed through to get to an active element in the last portlet in a document. To solve this problem in XHTML 1.x we are incorporating a feature in Firefox and IE to define the tabindex for -1. This allows a script author to give an element focus without placing it in the tab order.

[En Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)]

An important addition in the States and Properties Module for Accessible Rich Internet Applications is new extensions of tabindex. Now, with the tabindex change, the author is allowed to give any element keyboard focus (and not just form elements or anchors). In this paradigm shift, the user experience should be to use tabbing or keyboard mnemonics to move focus to widgets on the Web page and then use the arrow keys to navigate the object.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

XHTML 2 permitirá ya que todos los elementos de la página reciban el foco, y por tanto ya no será necesario lo que en este apartado se ha dicho.

Roles

Lo segundo que necesita la AT es obtener información sobre la semántica de partes específicas del documento, de aquellas que van a cambiar dinámicamente, o que contienen elementos que lo van a hacer. El div que contiene la noticia no es una etiqueta con significado semántico, y tampoco existe una etiqueta "menú", "pestaña" o "árbol", así que en la etiqueta div añadiremos el rol, la función.

The incorporation of Roles for Accessible Rich Internet Applications is a way for an author to provide proper type semantics on custom widgets (elements with repurposed semantics) to make these widgets accessible, usable and interoperable with assistive technologies.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

Por ejemplo, para definir un menú de tipo árbol, utilizaríamos el rol "tree" y "treeitem":

<div role="wairole:tree" tabindex="-1"> <div role="wairole:treeitem" tabindex="-1"> [...]

En este enlace puedes ver un listado de todos los roles.

Estados y propiedades

Lo tercero que necesita saber la AT es el estado y propiedades del objeto. Siguiendo con el ejemplo del menú de tipo árbol, necesitará saber si está plegado o no. Lo indicaríamos de la siguiente manera:

<div role="wairole:treeitem" tabindex="-1" aaa:expanded="true">

"aaa" significa: accessible adaptable applications

En este enlace puedes ver un listado de estados y propiedades.

Sin embargo, no basta con indicar su estado, sino que además, si este cambia, deberá modificarse para que la AT registre el cambio y pueda informar de ello al usuario. Es decir, cada vez que el árbol se pliegue o despliegue deberá cambiar su estado. Este cambio se realiza por javascript de la siguiente manera.

JavaScript can then manipulate the widget via the DOM. However, because States and Properties are mapped to the accessibility platforms, the assistive technology and user agents can understand the widget behavior and respond appropriately.
java script snippet : if ((event.type == "keyup" && event.button == 0){ // Toggle checkbox var checkbox = event.target; if (checkbox.getAttributeNS("http://www.w3.org/2005/07/aaa", "checked") == "true") { checkbox.removeAttributeNS("http://www.w3.org/2005/07/aaa", "checked"); } return false; // Don't continue propagating event } return true; // Browser can still use event }

[Ejemplo tomado de: States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties) ]

Así como los estados y propiedades deben modificarse, los roles NO.

Roles are element types and should not change with time or user actions. […] If the old element type is be replaced by a new one, the corresponding element and its subtree should be removed from the document and a new one inserted containing the new role type.

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

En resumen:

An application becomes accessible when:

Each element or widget has full and correct semantics that fully describes it's behavior (using element names or roles).
The relationships between elements and groups are known
States, properties, and relationships are valid for each elements behavior and are accessible via the Document Object Model [DOM].
There is an element having the correct input focus.

Estos son los pasos que WAI-ARIA indica que hay que seguir:

Step 1: Use your native mark up as well as you can
Step 2: Find the right roles
Step 3: Look for groups
Step 4: Build relationships
Step 5: Set properties
Step 6: Associate style sheet selectors with accessibility states and properties

[En Roles for Accessible Rich Internet Applications (WAI-ARIA Roles)]

¿Puedo aplicar WAI-ARIA a cualquier página HTML o XHTML?

At this time, the primary effort in the W3C WAI Protocols and Formats working group is to focus on an extension to XHTML 1.1. It should be noted that XHTML 1.0 could also be enhance to support this extension through the use of a hybrid DTD which incorporates the extensions. The reason for focusing on XHTML 1.X is that XHTML is extensible through the use of namespaces and because it is renderable by today's browses.
[…]
This roadmap is designed to address the accessibility of dynamic, scripted, Web content that may be rendered in today's browser while bridging to future declarative standards, such as XHTML2, in the W3C. The extensions being created for XHTML 1.X are intended to be cross-cutting.

[En Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)]

Como se ve, en espera del estándar XHTML 2, WAI-ARIA se enfoca a XHTML 1.X. Si te interesa su aplicación a HTML:

There is no normative way to apply roles in HTML, but it is recommended to use the HTML implementation technique.
[...]
HTML documents do not support namespaces, so the required accessibility role and state metadata can not be included directly in these documents. In HTML 4, you can define the accessible role and accessible states as keywords in the class attribute, then use an ECMAScript library to parse the class keywords and copy them into the appropriate role and state namespaces.

[En Embedding Accessibility Role and State Metadata in HTML Documents]

El uso de "namespaces" para incorporar información de roles e información de estados y propiedades en XHTML 1.1 sería así (los ejemplos que incluyo son tomados literalmente de Roles for Accessible Rich Internet Applications (WAI-ARIA Roles):

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
xmlns:waistate="http://www.w3.org/2005/07/aaa">

<body>
<div role="wairole:menu" waistate:haspopup="true">
File
</div>    
</body>
</html>

El uso de namespaces para incorporar información de roles e información de estados y propiedades en XHTML 1.0 sería así:

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"
xmlns:xhtml10="http://www.w3.org/1999/xhtml"
xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#">

<body>
<table id="table1" xhtml10:role="wairole:grid">
...
</table>
</body>
</html>

For developers using Firefox 1.5, the role attribute was used from the XHTML 2 namespace. Creation of an XHTML role module for XHTML 1.X only occurred recently. For those doing development on Firefox 1.5, the role attribute from XHTML 2 must be used. This being corrected in Firefox 2.0 although Firefox 2.0 will support role in both the old XHTML 2 and 1.1 namespaces. For Firefox 1.5 supporters, this is the
equivalent markup.

Example: Use of namespaces to incorporate role information information into XHTML 1.x for Firefox 1.5

<?xml version="1.1" encoding="us-ascii"?>
<!DOCTYPE html PUBLIC "Accessible Adaptive Applications//EN" 
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:wairole="http://www.w3.org/2005/01/wai-rdf/GUIRoleTaxonomy#"
xmlns:x2="http://www.w3.org/2002/06/xhtml2">
<body>
<div x2:role="wairole:menu">
File
</div>
</body>
</html>

¿Los navegadores y AT ya soportan WAI-ARIA?

Avelino Herrera comentaba que había hecho pruebas con FireVox (lector de pantalla para Firefox) y que era compatible con WAI-ARIA, siendo capaz de dictar perfectamente todo el contenido que se añadía dinámicamente a la página mediante Javascript.

Yo también lo he comprobado y es cierto. En el último apartado citaré varios ejemplos para que podáis comprobarlo vosotros mismos.

Firefox Accessibility Extension Beta version 1.1 es otra extensión de Firefox que añade una nueva barra de herramientas al navegador. Uno de sus menús se llama "Scripting" y contiene todo lo relacionado con WAI-ARIA como puedes ver en esta imagen:

Por ejemplo, la "List of DHTML Widgets" mostraría el siguiente aspecto

Como ves, se muestra un listado de los roles, su tabindex, si ha cambiado su estado, etc.

A continuación incluyo la lista de implementaciones de WAI-ARIA en navegadores y tecnologías asitivas que se recoge en su Hoja de ruta:

Firefox 1.5 (including MSAA support)
GW Micro Window-Eyes 5.5 - with Firefox support
JAWS 7.0 with Firefox support(partial)
Windows Magnifier (with IE or Firefox 1.5)
Internet Explorer from DOM API
Mozilla Firefox Test samples
Dojo JavaScript Toolkit
Mozilla Firefox Accessibility Extensions Test Tool and test suite
Mozilla Firefox ARIA to Accessibility API mapping
Bindows Object Oriented Platform for AJAX Development
WAI Role Taxonomy Extension Tool

NOTA 2009: Soporte para WAI-ARIA en Internet Explorer 8, "Internet Explorer 8 emplea información de rol, estado y propiedades a través de ARIA para communicar con las ayudas técnicas."

NOTA 2009:

[09-06-09] "Safari 4 ya está aquí" de Programar a ciegas
Lo más importante es que Safari implementa HTML5 y WAI ARIA y voiceOver es compatible con las páginas que incorporen estas tecnologías.

Con Safari 4 el acceso a la nueva Web resultará posible para aquellos que utilicen ordenadores con el sistema operativo de Apple. La versión para Ms Windows de Safari resulta incompatible con los lectores de pantallas más conocidos, como NVDA, JAWS y Window eyes.

Como se ve, el único framework de AJAX que lo implementa en Dojo... algo a tener en cuenta.

Muy interesante también la lista de roles que soporta Firefox en combinación con distintas AT.

Ejemplos

Incluyo a continuación una lista de ejemplos de aplicación de WAI-ARIA para que podáis probar vosostros mismos instalándoos alguna extensión/aplicación del apartado anterior:

Diversos ejemplos clasificados en simples y complejos.
Por ejemplo esta "Grid" compleja.
Cantidad y variedad de ejemplos del iCITA (Illinois Center for Information Technology Accessibility)
Si os interesan ejemplos sobre "AJAX live regions", es recomendable el artículo del 30 de enero de 2007 WAI-ARIA Live Regions de Juicy Studio, que puedes verlo aplicado en los ejemplos de Accessible AJAX.

Enlaces de interés

Ejemplos

Simple AJAX Application

Utilidades

La extensión de accesibilidad de JuicyStudio soporta ARIA, por lo que será de ayuda a la hora de avaluar las webs que se vayan aplicando la especificación.

Generales

Accessible Rich Internet Applications (WAI-ARIA) Suite Overview en WAI
WAI-ARIA Best Practices
Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap). 20 diciembre 2006
Roles for Accessible Rich Internet Applications (WAI-ARIA Roles). 1 junio 2007
States and Properties Module for Accessible Rich Internet Applications (WAI-ARIA States and Properties). 1 junio 2007
Nota de prensa del 26 de septiembre de 2006: El W3C publica una 'Hoja de ruta' para las aplicaciones de Internet enriquecidas accesibles (WAI-ARIA)
XHTML Role Attribute Module del W3C (13 noviembre de 2006)
XML Events 2 del W3C (16 febrero 2007)
Firefox Accessibility Extension Beta version 1.1

Artículos

"Introduction to WAI ARIA", de Dev.Opera
Introducción a WAI-ARIA (octubre 2008)
WAI-ARIA, una aproximación (febrero 2009)
How Can I Validate (X)HTML + ARIA?, de Paciello Group
Using WAI ARIA Landmark Roles, de Paciello Group
Accessible Web 2.0 Applications with WAI-ARIA de Martin Kliehm (9 de abril de 2007)
Redesigning with HTML 5 and WAI-ARIA
WAI-ARIA: Contenido Web Enriquecido Accesible de Accesibilidad, Usabilidad y Estándares Web (4 junio 2007)
AJAX Accesible de Olga Carreras (febrero de 2007)
Accessible AJAX
WAI-ARIA Live Regions de Juicy Studio (30 enero 2007)
WAI-ARIA: Aplicaciones web AJAX accesibles de Avelino Herrera (27 de abril de 2007)

Artículos relacionados
[26-05-07] AJAX accesible I
[22-10-07] AJAX accesible III: HIJAX
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Formulario con varios botones. Implementación usable y accesible

2007-07-19T14:59:00.006+02:00

Imagina que tenemos que realizar un formulario muy sencillo:

El formulario consta de un campo NIF de tipo texto y tres botones que realizan tres operativas diferentes: "Crear usuario", "Eliminar usuario" y "Cancelar".

No parece muy complicado ¿verdad? De hecho existen muchas formas de implementarlo; el problema es que la mayoría de ellas son inaccesibles.

El objetivo de este artículo es explicar qué implementaciones son posibles y clasificarlas en:

NO accesible/NO nos sirve

Accesible/Nos sirve pero NO es recomendable

Accesible y recomendable ¡bingo! ¡usémoslo!

Nota: no entraremos en discusiones acerca de si la operativa de "Crear Usuario" y "Eliminar Usuario" deberían ser dos páginas diferentes, con un único botón "Aceptar", etc. Es un ejemplo para ilustrar el problema de los formularios con varios botones.

Implementar la acción por Javascript

Clasificación:NO accesible/NO nos sirve

Un desarrollador novato (llamémosle Hugo) saldrá del paso de la siguiente manera:

     <input type="button" 
value="Crear usuario" 
id="nuevo"
name="nuevo" 
onclick= "document.form1.action = 'nuevo.jsp'; 
document.form1.submit()" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar"
onclick= "document.form1.action = 'eliminar.jsp'; 
document.form1.submit()" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" 
onclick= "self.location.href = 'principal.jsp'" />

Si tenemos suerte y a Hugo se le ha estropeado el ratón, pulirá su código así:

<input type="button" 
value="Crear usuario" 
id="nuevo"
name="nuevo" 
onclick="document.form1.action = 'nuevo.jsp';
document.form1.submit()"
onkeypress="document.form1.action = 'nuevo.jsp'; 
document.form1.submit()" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar"
onclick="document.form1.action = 'eliminar.jsp'; 
document.form1.submit()" 
onkeypress="document.form1.action = 'eliminar.jsp';
document.form1.submit()" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" 
onclick="self.location.href = 'principal.jsp'" 
onkeypress= "self.location.href = 'principal.jsp'" />

Posiblemente Hugo, en un momento de lucidez, comprenda que si el primer botón es de tipo "submit", se convertirá en el botón por defecto, el que se ejecute al pulsar "intro" y además se ahorra una función.

Gracias a ello, un usuario que tenga desactivado el javascript o su user-agent no lo admita, al menos podrá crear un usuario:

<form action="nuevo.jsp"
name="form1"
id="form1"
method="post">      

[...]

<input type="submit" 
value="Crear usuario" 
id="nuevo"
name="nuevo" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar"
onclick="document.form1.action = 'eliminar.jsp';
document.form1.submit()" 
onkeypress="document.form1.action = 'eliminar.jsp';
document.form1.submit()" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" 
onclick="self.location.href = 'principal.jsp'" 
onkeypress="self.location.href = 'principal.jsp'" />

Si Hugo tiene muchos formularios, terminará descubriendo las funciones javascript y limpiando su código:

<script type="text/javascript">
<![CDATA[
function someter(id){
document.form1.action=id;
document.form1.submit();
}

function navegar(id){
self.location.href=id;
}
]]>

</script>
[...]

<form action="nuevo.jsp"
name="form1"
id="form1"
method="post">      

[...]

<input type="submit" 
value="Crear usuario" 
id="nuevo"
name="nuevo" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar"
onclick="someter('eliminar.jsp')" 
onkeypress="someter('eliminar.jsp')" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" 
onclick="navegar('principal.jsp')" 
onkeypress="navegar('principal.jsp')" />

Si Hugo asiste a un cursillo básico acerca de las bondades de separar la presentación, del contenido y de la programación, entonces quizás tengamos la suerte de ver javascript no-intrusivo:

[en el fichero funciones.js]
function init(){
document.getElementById("eliminar").onclick =  
function(){
document.form1.action= "eliminar.jsp";
document.form1.submit();
}

document.getElementById("eliminar").onkeypress =  
function(){
document.form1.action= "eliminar.jsp";
document.form1.submit();
}
document.getElementById("cancelar").onclick =  
function() {
self.location.href="navegar.jsp"; 
}
document.getElementById("cancelar").onkeypress = 
function() {
self.location.href="navegar.jsp"; 
}
}
window.onload=init;      


[en la página]

<form action="nuevo.jsp"
name="form1"
id="form1"
method="post">      

[...]

<input type="submit" 
value="Crear usuario" 
id="nuevo"
name="nuevo" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" />

En fin, podríamos seguir mejorando y depurando el código o poner otras alternativas similares que se ven a menudo, por ejemplo ir cambiando dinámicamente por javascript un campo "hidden" donde se guarda el destino final de la página, y mediante el evento "onsubmit" del formulario cambiar el "action" del formulario, etc.

Pero todas ellas nos llevarán a un callejón sin salida, porque un usuario que no tenga activado el javascript o su user-agent no admita javascript, en el mejor de los casos podrá ejecutar sólo la acción "Crear Usuario".

Varios formularios

Clasificación:NO accesible/NO nos sirve

Hugo le ha pedido ayuda a Pedro, quien después de pensar un rato ha tenido una idea genial: hagamos que todos los botones sean de tipo "submit" y para evitar tener que modificar por javascript el "action" del formulario, ¡hagamos varios formularios!. Dicho y hecho.

Lo primero que se les ocurre es encerrar cada botón en un formulario:


<form name="form1" [...]
<input type="submit" [...]
</form>
<form name="form2" [...]
<input type="submit" [...] 
</form>
<form name="form3" [...] 
<input type="submit" [...]
</form>

Pronto se dan cuenta de que esto no lleva a ninguna parte porque el campo de texto NIF no está dentro del formulario y no se enviará su contenido con el "submit".

Pedro, que no se rinde fácilmente, decide que lo que hay que hacer es anidar los formularios:


<form name="form1" [...] 
<form name="form2" [...]
<form name="form3" [...]

[aquí nuestro campo de texto NIF]

<input type="submit" [...]
</form> 
<input type="submit" [...] 
</form> 
<input type="submit" [...] 
</form>

Pedro y Hugo comprueban que esto no funciona... lástima, no se pueden anidar formularios.

Alternativa accesible con `<noscript>`

Clasificación:Accesible/Nos sirve pero NO es recomendable

Hugo y Pedro recuerdan que Lisa hizo un curso de accesibilidad y le piden consejo. Ella lo ve claro: "utilicemos la etiqueta <noscript>". Lisa se pone de inmediato a teclear, añadiendo al final del código que vimos en el primer apartado el siguiente <noscript>:


<form action="nuevo.jsp"
name="form1"
id="form1"
method="post">      

[...]

<input type="submit" 
value="Crear usuario" 
id="nuevo"
name="nuevo" />

<input type="button"
value="Eliminar usuario"
id="eliminar"
name="eliminar" />

<input type="button"
value="Cancelar"
id="cancelar" 
name="cancelar" />

</form>

<noscript>
<p>Su navegador no admite javascript.</p>
<ul><li>Para crear un nuevo usuario pulse el botón 
"Crear usuario" del formulario anterior</li>
<li>Para cancelar y volver a la página anterior
pulse el siguiente enlace: 
<a href="principal.jsp">Cancelar</a></li>
<li>Para eliminar el usuario, rellene el
formulario que le presentamos a continuación:</li>
</ul>

<h2>Eliminar usuario</h2>

<form action="eliminar.jsp" method="post" 
name="form2" id="name="form2">

<label for="nifacc">NIF*:
<input id="nifacc" name="nifacc" />
</label>

<input type="submit" 
value="Eliminar usuario" 
id="eliminaracc"
name="eliminaracc" />

</form> 

</noscript>

Lisa les propone mostrar la página a varios compañeros, desactivándoles el javascript, para ver si les queda clara la forma de interactuar con el formulario. Estos compañeros ven la página así:

Pronto se dan cuenta de que puede que la página sea accesible, pero no resulta demasiado usable, parece que los usuarios son reacios a leer instrucciones. Después de intentar reiteradamente interactuar con los primeros botones y maldecir porque no funcionan, algunos se deciden a leer el texto explicativo. En el mejor de los casos han perdido mucho tiempo, en el peor se han rendido.

Por otro lado, una vez superada la euforia inicial, Pedro y Hugo empiezan a reflexionar sobre el sobreesfuerzo de programación y el aumento del peso de la página, esta solución empieza a ser poco práctica para implementar y mantener en todos los formularios de la aplicación, bastante más complejos que este.

La última razón para desechar esta opción se la proporciona Lisa: ups! se le olvidó comentar que la etiqueta "noscript" ya no es bien vista por el W3C y no estará en el estándar XHTML2.0

¿Y si utilizamos las etiquetas `<a>` o `<button>`?

Clasificación:NO accesible/NO nos sirve

A estas alturas se ha extendido el rumor y es la comidilla de la oficina que Hugo, Pedro y Lisa no son capaces de crear un simple formulario compuesto de un campo y tres botones. Así que Gabi, a quien le atraen los marrones más que a una mosca, se deja caer por ahí.

"Si no podéis usar botones, ¿por qué no usáis etiquetas <a> que con el estilo simulen un botón? Mejor aún, ¿por qué no utilizáis <button>?"

<button> es una de esas etiquetas que apenas se usan, hasta tal punto que llegamos a dudar de que sea estándar. Pero lo es, incluso en la especificación XHTML 1.1.

Un <button> puede contener una etiqueta <a>, por tanto PARECE que es una ventaja utilizar <button> en vez de utilizar <a>: ya que tendrá aspecto de botón y se hundirá al pulsarlo sin necesidad de simularlo con estilos, además es un elemento de formulario y por ello PARECE más apropiado.

Y digo PARECE porque <button> en realidad no se utiliza debido a que no funciona correctamente en Explorer.

Pedro y Hugo tienen otras razones para no usar la alternativa de Gabi, bien con enlaces bien con botones "nos sirve para el botón 'Cancelar' porque sólo navega, pero con el resto de botones queremos someter la página, así que necesitaríamos añadir al enlace, al botón o al enlace dentro del botón un evento javascript que enviara el formulario, y si hacemos el botón de tipo 'submit' estaríamos también igual que antes".

Otro callejón sin salida.

XForm

Clasificación:NO accesible/NO nos sirve

A estas alturas, Hugo, Pedro, Lisa y Gabi deciden que necesitan a Feder, el friki de la empresa, así que se dirigen en procesión a su mesa.

"XForm, esto se soluciona con XForm". Sus compañeros le miran con devoción, no tienen ni idea de lo que les habla, pero por lo visto están salvados.

XForm,- les explica Feder-, es recomendación oficial del W3C desde marzo de 2006, es la nueva generación de formularios que nos permite separar la presentación del contenido.

[en el modelo de datos]
<model>
[...]
<submission action="nuevo.jsp" method="post"
id="crear"/>
<submission action="eliminar.jsp" method="post"
id="eliminar"/>
<submission action="principal.jsp" method="post" 
id="cancelar"/>
[...]




[en el body]

[...]

<submit submission="crear">
<label>Crear usuario</label>
</submit>

<submit submission="eliminar">
<label>Eliminar usuario</label>
</submit>

<submit submission="cancelar">
<label>Cancelar</label>
</submit>

Feder les indica dónde pueden ver un ejemplo.

Al cabo de un rato regresan a la mesa de Feder: hemos probado con Firefox, con Explorer... pero no conseguimos que funcione.

Bueno, es que actualmente ningún navegador soporta XForm nativamente,- les explica,- pero existen plugins y extensiones para Explorer y Firefox.

Sus compañeros le hacen ver que no pueden obligar al usuario a utilizar determinado navegador y además instalarse un plugin o extensión.

Bueno,- insiste Feder- también se pueden convertir en el servidor, en tiempo de ejecución, a formularios de HTML, hay proyectos de código abierto.

También podéis echar un vistazo a AJAXForms,- añade Feder- que transforma documentos XHTML/XForms en páginas HTML con javascript, cuya comunicación con el servidor se restringe al intercambio de datos utilizando técnicas AJAX.

Sus compañeros se deshinchan... si transformamos los documentos XHTML/XForms en páginas HTML con javascript... ¿qué hemos ganado? Estamos otra vez en el punto de partida.

MVC

Clasificación:Accesible y recomendable ¡bingo! ¡usémoslo!

Hugo les da las gracias a todos y decide enviar un mensaje a la lista de correo de la empresa pidiendo más ideas. No tarda en llegar la respuesta.

<form action="./UsuariosServlet"
name="form1"
id="form1"
method="post">      
[...]
<input type="hidden" 
value="Usuario" 
id="pageOperation"
name="pageOperation" />
<input type="submit" 
value="Crear usuario" 
id="evento_nuevo"
name="evento_nuevo" />
<input type="submit"
value="Eliminar usuario"
id="evento_eliminar"
name="evento_eliminar" />
<input type="submit"
value="Cancelar"
id="evento_cancelar" 
name="evento_cancelar" />
</form>

Limpio, transparente, fácil de mantener, 100% accesible... Dejemos que la aplicación, en el servidor, en función del valor del "pageOperation" y del botón pulsado (fácil de identificar porque su "name" comienza con "evento") decida qué acción realizar.

Importante:

No utilizar <button type="submit" ... en vez de <input type="submit" ... puesto que <button> funciona mal en Explorer y enviará todos los botones y por tanto no podremos saber en el servidor cuál se ha pulsado.
Si la página tienen validaciones javascript en función de las cuales se hace o no el "submit" (por ejemplo mediante un evento asociado al "onsubmit" del "form") siempre hay que realizar también estas validaciones en el servidor, puesto que al tener botones "submit", si el usuario no tiene javascript activo o su "user-agent" no lo soporta, el formulario se enviará porque se ignorará la validación javascript. Me parece muy interesante la reflexión que hace b-Make acerca de las páginas que contienen una cláusula legal que hay que aceptar para enviar el formulario.

NOTA: Toda la historieta de fondo es inventada con personajes ficticios, así me ha parecido más amena.

Artículos relacionados:

AJAX accesible

2007-05-26T23:24:00.006+02:00

El objetivo de este artículo es reflexionar sobre los retos de accesibilidad que supone un desarrollo con AJAX. Me voy a centrar en la accesibilidad, sin entrar en los problemas de usabilidad que plantea (seguro que a todos os suenan los diez famosos problemas), tema que abordaré otro día.

Entiendo que si sigues leyendo es porque sabes lo que es AJAX como técnica de enriquecimiento de aplicaciones web, si no es así te recomiendo que antes de continuar le eches un vistazo a “AJAX: un nuevo acercamiento a Aplicaciones Web“ con la traducción del famoso artículo “Ajax: A New Approach to Web Applications” de Jesse James Garret.

AJAX no es un fin, es un medio

Mucha gente dará por sentado que si alguien preocupado por temas de usabilidad y accesibilidad hace un artículo sobre AJAX es para concluir: “no uséis AJAX, es el demonio, AJAX no es accesible”.

Nada más lejos de mis intenciones. Me gusta AJAX, he trabajado con AJAX y recomiendo a menudo AJAX. Y aquí entran las matizaciones.

Recomiendo AJAX para problema concretos y siempre con sentido común.
No recomiendo AJAX a toda costa, para todo, sólo porque los demás lo están usando o con el único afán de hacer alarde del dominio de la tecnología de moda. Usar AJAX con cualquier otro objetivo que no sea el de hacer más fácil, satisfactoria y productiva la experiencia del usuario, es simplemente una estupidez, y lo que es peor, un error que se descubre demasiado tarde.

En definitiva: AJAX no es un fin, es un medio para mejorar la experiencia del usuario. Parece evidente, pero un inquietante número de arquitectos y diseñadores software pierden la perspectiva.

AJAX con sentido común

Creo que Alex Bosworth, en su famoso artículo “10 Places You Must Use Ajax” recomienda muy acertadamente para qué usar o no usar AJAX:

Recomienda usar AJAX para:

Form driven interaction.
Deep hierarchical tree navigation.
Rapid user-to-user communication.
Voting, Yes/No boxes, Ratings submissions.
Filtering and involved data manipulation.
Commonly entered text hints/autocompletion.

NO recomienda usar AJAX para:

Simple forms.
Search.
Basic navigation.
Replacing a large amount of text.
Display manipulation.
Useless widgets.

Dicho esto, es cierto que un desarrollo con técnicas AJAX plantea interesantes retos de accesibilidad, y para afrontarlos deberemos partir de dos premisas básicas:

La inmensa mayoría de los problemas tienen solución, unas veces será más fácil que otras, unas veces será más costosa que otras, pero siempre hay una solución. Al fin y al cabo en eso consiste nuestro trabajo ¿no? en encontrar soluciones a los problemas.
Nada es de por si accesible o no accesible, ni una página, ni un script; los que los hacen inaccesibles son siempre los desarrolladores, por falta de conocimientos o por falta de interés.

AJAX y navegadores

AJAX se basa en el uso del objeto XMLHTTPRequest mediante Javascript ejecutado en el navegador para realizar peticiones asíncronas al servidor, y en la manipulación, también por Javascript, del Document Object Model (DOM) para visualizar e interactuar dinámicamente con la información presentada.

Por tanto, aunque AJAX no necesita ningún tipo de plugin para el navegador, requiere que el navegador soporte y tenga activo el Javascript, y que además soporte el objeto XMLHTTPRequest. En Internet Explorer 5 y 6, además, es necesario tener la secuencia de comandos ActiveX activada, ya que, en estas versiones, la implementación de Microsoft (denominada XMLHTTP) es un componente ActiveX (mientras que en versiones más recientes de los navegadores está implementado como un objeto nativo).

En resumen, los navegadores que soportan AJAX, siempre y cuando tengan Javascript activado, y en su caso la secuencia de comandos ActiveX, son:

Microsoft Internet Explorer para Windows versión 5.0 y superiores, y los navegadores basados en él (por ejemplo Maxthon)
Navegadores basados en Gecko como Mozilla, Mozilla Firefox, SeaMonkey, Camino, Flock, Epiphany, Galeon y Netscape versión 7.1 y superiores
Navegadores con el API KHTML versión 3.2 y superiores implementado, incluyendo Konqueror versión 3.2 y superiores, Apple Safari versión 1.2 y superiores.
Opera versión 8.0 y superiores
Dispositivos móviles: Opera Mobile Browser 8.0 basado en Safari y API KHTML, que soporta aplicaciones desarrolladas en AJAX gracias a su motor de Javascript y su seguimiento del DOM. El mes pasado Mozilla lanzaba Minimo Mobile Browser 0.2 compatible con Windows Mobile 5.0, y que soporta Javascript y AJAX.

[Si os interesa el uso de AJAX en entornos móviles, es interesante echar un vistazo a MOJAX (Mobile AJAX Application Frameworks)]

Los navegadores que NO soportan AJAX son:

Opera 7 y anteriores
Microsoft Internet Explorer para Windows versión 4.0 y anteriores
IE para Macintosh, todas las versiones
Dillo
Navegadores basados en texto como Lynx y Links
Navegadores para incapacitados visuales (braille)
Dispositivos móviles: Deepfish de Microsoft, presentado también hace un par de meses no soporta controles ActiveX, AJAX, cookies, ni JavaScript.

AJAX accesible

El punto de verificación 6.3 de las Pautas de Accesibilidad de la WAI dice así:

Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible.

Dicho punto es de Prioridad 1, es decir, es necesario para alcanzar un nivel de adecuación Simple A. Por tanto, para asegurar la accesibilidad de nuestra aplicación, se debe ofrecer una alternativa para el contenido mostrado dinámicamente por Javascript.

Si se utiliza un framework para implementar técnicas AJAX, bien sea open source, comercial o propio de nuestra organización, habrá que asegurarse de que éste ofrece una alternativa accesible adecuada para cada componente AJAX y de que tienen en cuenta las incompatibilidades entre navegadores. [1]

Y por supuesto, todos aquellos contenidos que se inserten dinámicamente en la página deben cumplir las normas de accesibilidad de ese elemento, tal y como las cumplen los demás elementos de la página. Y por tanto, si se utiliza un framework, asegurarse de que cumpla este requisito. [2]

Y después de todo lo dicho, llegamos a lo realmente importante, al "meollo" del asunto.

Cuando indico que es necesario ofrecer una alternativa accesible NO me refiero a crear dos aplicaciones diferentes, una con AJAX y otra sin AJAX. La WAI desaconseja explícitamente los sitios alternativos por no ser una solución integradora, eso sin contar con el elevado coste de realizar dos versiones, las dificultades y el coste de su mantenimiento (como leí en el blog de Torres Burriel, Jesús García lo definió muy acertadamente como “casa de dos puertas es difícil de guardar” ).

El objetivo, por lo tanto, es conseguir hacer accesible una única aplicación.

¿Cómo podemos pues ofrecer alternativas accesibles para los desarrollos AJAX sin crear dos aplicaciones diferentes?

Antes de entrar en el tema me gustaría hacer un inciso sobre la etiqueta "noscript", de la que a menudo se echa mano. Por ejemplo, imaginemos un menú dinámico implementado por AJAX, de tal manera que al pulsar en una de las opciones principales del menú, se consulta al servidor su árbol de submenús para pintarse en la página.

Puede pensarse que una buena alternativa accesible sería en la etiqueta "noscript" incluir todo el árbol del menú (o si este es muy extenso, un enlace a un página con todas las opciones de menú). Pero hay que advertir que la etiqueta "noscript" no estará en el estándar XHTML2.0

De todas formas, como voy a explicar ahora, hay una manera más robusta de hacer las cosas.

Para empezar, tu aplicación debe utilizar un patrón MVC (Modelo-Vista-Controlador) que separe los datos de la aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos… y si no… vamos “apañaos”.

Por otra parte, es graciosa tanta preocupación por separar el contenido, la presentación y el comportamiento, para luego encontramos las páginas llenas de Javascript. No me refiero a que el código no esté en ficheros JS (faltaría más), sino a tener el código Javascript mezclado con el código HTML, empozoñándolo al estilo de <input onClick=”mifuncion()”>.

Todo el código javascript debe ser no intrusivo, invisible, de tal manera que no afecte su desactivación al funcionamiento de la página, y por supuesto tener cuidado con el tipo de eventos que se manejan (el evento onClick será inservible, por ejemplo, a un usuario que no disponga de ratón).

[Si lo de javascript “no intrusivo” te suena a chino, ya te estás yendo a Unobtrusive Javascript y a Behaviour].

Bien, tenemos pues una aplicación como dios manda en la que además, desde la primera petición al servidor de nuestras páginas, éste identifica el User-Agent en una cabecera del protocolo http, pudiendo guardar esta información en una variable. Dicha variable será recuperable en toda la aplicación y servirá a los componentes AJAX de nuestro framework para que decidan cómo deben presentarse (en combinación con la identificación en su código generado de si está activado el Javascript en el navegador).

Cuando hablo de componentes AJAX, en realidad pienso siempre en un framework personal o corporativo de mi organización o de mi cliente. Desconfío de los grandes frameworks de AJAX por varias razones: tienen bugs al estar todavía poco maduros y no siempre hacen todo lo que el cliente/usuario/guía de estilo te exige que hagan. Prefiero un framework personal, al que le puedes echar mano con facilidad, sólo con los componentes que necesitas, a la medida de tus necesidades, y por supuesto basado en prototype. [3]

En este contexto, un componente AJAX sería, por ejemplo, una tabla con ordenamiento de columnas y paginación mediante AJAX, o un menú dinámico que consulte por AJAX las subopciones que ha de desplegar antes de repintarse.

Nuestro componente “tabla” define internamente dos comportamientos en función del User-Agent: cómo pintarse para el caso de que sí admita javascript y en el de que no lo admita.

Por otro lado, hay que decir que la variante accesible dependerá mucho del tipo de componente; por ejemplo:

Si se trata de un autocompletar en una caja de texto, puede decidirse que no es necesario disponer de una alternativa accesible, puesto que no tenerla no merma en nada la interacción con el formulario.
En el caso de una validación campo a campo de un formulario asíncronamente mediante AJAX, siempre que el formulario tenga un botón submit que valide los campos en servidor, no necesitará mayor alternativa.
En el caso de las capas de detalle (o balones) que aparecen sobre una celda de una tabla a modo de resumen (para no tener que navegar al detalle completo si no se desea), mi punto de vista es que si existe el enlace de detalle en cada fila, tampoco es necesaria otra alternativa accesible.

Por lo tanto, si cada componente de nuestro framework tiene correctamente implementado internamente su comportamiento en función de las capacidades del navegador y del contexto de ejecución, este framework conseguirá el objetivo de cualquier diseño técnico orientado a componentes: independizar a la aplicación que los utiliza acerca de sus particularidades de implementación, lo que en este caso significa, en un caso ideal, que el desarrollador de la aplicación no deberá preocuparse acerca de las alternativas accesibles para los elementos enriquecimiento utilizados.

De esta manera, la alternativa accesible es sólo a nivel de capa de presentación y sólo a nivel de componentes, no de aplicación. [4]

Es necesario conocer...

Si os interesa este tema, son imprescindibles los 40 tutoriales y artículos de AJAX y accesibilidad.

También por supuesto es imprescindible conocer la hoja de ruta WAI-ARIA (Roadmap for Accessible Rich Internet Applications (WAI-ARIA)), presentada por la W3C en septiembre de 2006.

[...] ofrece una propuesta global que permita asegurar la interoperabilidad entre las aplicaciones de internet enriquecidas y las tecnologías asistivas utilizadas por personas con discapacidad. La propuesta se apoya en tecnologías ya desarrolladas o que están en desarrollo por el W3C, tales como el Modulo del Atributo Role de XHTML.

[En W3C España]

[WAI-ARIA Roadmap] [WAI-ARIA Roles] [WAI-ARIA States and Properties]

[Ver artículo AJAX accesible II: WAI-ARIA]

Por último comentar el artículo "Making Ajax Work with Screen Readers" de Gez Lemon and Steve Faulkner, que proponen manejar el búfer virtual del lector de pantalla JAWS como vía para hacer accesible una aplicación web.

Como complemento de nuestra aplicación puede ser buena idea, pero no es un estándar, ni JAWS es el único software para usuarios con deficiencias visuales, ni por supuesto la accesibilidad está pensanda sólo para este colectivo, como a veces parece que mucha gente piensa.

En resumen, buenas prácticas

Respetar las pautas de accesibilidad en todos los elementos de las páginas aunque estén insertados dinámicamente.
Utilizar un patrón MVC que facilite la separación entre las lógicas de control y flujo de navegación (Controlador), de negocio y acceso a datos (Modelo), y de presentación en los distintos clientes, dispositivos y contextos (Vista).
Utilizar Javascript no intrusivo.
Conocer los navegadores para discapacitados visuales y comprobar que pueden interactuar con la aplicación: eventos adecuados, foco accesible, etc.
Detectar el User-Agent del usuario desde la primera petición guardando esta información para que sea recuperable por todas las páginas de la aplicación.
Crear una serie de módulos, de componentes AJAX, que en función del User-Agent y de si está habilitada la ejecución de Javascript sepan como “pintarse”, dando por tanto una opción alternativa accesible dependiendo del componente en cuestión.
Acatar la hoja de ruta de la WAI que permitirá por ejemplo informar mediante roles al usuario del funcionamiento exacto de la aplicación cuando los navegadores las implementen.

Notas

[1] Por ejemplo, Rails incluye alternativas accesibles para formularios que se envían por Javascript, incluyendo un argumento que indica a qué URL enviarlo si no está habilitado el Javascript.

[2] Por ejemplo, Dojo 0.4 empieza a ofrecer funcionalidad completa desde teclado e integración con modos de alto contraste así como con lectores de pantalla para las personas discapacitadas. dojo.a11y: la fundación para la accesibilidad (a11y), ha implementado algunos de los widgets de esta versión e implementará algunos más para la siguiente (0.5).

[3] Esta afirmación la considero válida en la actualidad, pero la evolución tecnológica que puede haber en un plazo de 2-3 años en los frameworks y productos disponibles, su integración con los IDEs, etc, seguramente desaconsejará a corto plazo el uso de frameworks propios, cuya principal debilidad es el coste y dificultad del futuro mantenimiento evolutivo/correctivo/adaptativo/perfectivo).

[4] A nivel de lógica de negocio, no sería óptimo trabajar sólo con macropeticiones (peticiones globales de la página como en una aplicación sin AJAX) ni siquiera componer las macropeticiones a través de las micropeticiones (pequeñas peticiones sólo de aquellos contenidos de la página que vamos actualizar con AJAX), por ello, sí que será necesario que junto a las micropeticiones haya macropeticiones para las variantes accesibles.

Artículos relacionados
[07-09-07] AJAX accesible II: WAI-ARIA
[22-10-07] AJAX accesible III: HIJAX
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

Accesibilidad, firma electrónica y DNIe en el ámbito de las Administraciones Públicas

2007-04-13T19:43:00.000+02:00

Las aplicaciones Web de la Administración Pública española, desde el 1 de enero de 2006, deben cumplir los requisitos de accesibilidad W3C-WAI según la Ley 34/2002 [1] (aunque no se especifica el nivel mínimo de adecuación recomendado, el exigido en otros textos a nivel nacional [2] y desde la Unión Europea [3] es explícitamente la Doble A).

Por otro lado, la Administración Pública española debe ofrecer servicios de tramitación telemática [4], para los cuales se requiere firma electrónica, que permite identificar al firmante, verificar la integridad de su mensaje y asegurar su autoría, en caso de que éste decidiera negarla. [5]

La Ley distingue dos tipos de firma electrónica. La firma electrónica avanzada, que se define según la Ley 59/2003 [5] como:

"Art. 3.2 La firma electrónica avanzada es la firma electrónica que permite identificar al firmante y detectar cualquier cambio ulterior de los datos firmados, que está vinculada al firmante de manera única y a los datos a que se refiere y que ha sido creada por medios que el firmante puede mantener bajo su exclusivo control."

y la firma electrónica reconocida, que se define según la Ley 59/2003 [5] como:

"[...] que se define siguiendo las pautas impuestas en la Directiva 1999/93/CE como la firma electrónica avanzada basada en un certificado reconocido y generada mediante un dispositivo seguro de creación de firma. A la firma electrónica reconocida le otorga la Ley la equivalencia funcional con la firma manuscrita respecto de los datos consignados en forma electrónica.

[...]

Con ello se aclara que no basta con la firma electrónica avanzada para la equiparación con la firma manuscrita; es preciso que la firma electrónica avanzada esté basada en un certificado reconocido y haya sido creada por un dispositivo seguro de creación."

Un dispositivo seguro de creación como el DNIe.

No pretendo aquí incluir un manual de firma electrónica, pero sí que es necesario decir que, en ambos casos, el funcionamiento de la firma electrónica está basado es una clave pública y una clave privada. La clave privada sólo está en poder del propietario, que debe conservarla de forma segura, y por tanto jamás debe abandonar la máquina del cliente (en realidad, en el caso de la firma reconocida, ésta nunca sale del chip de la smartcard o dispositivo). Por ello no podremos realizar nunca la firma electrónica en el servidor.

Y entonces llegamos a donde quería ir a parar, que la firma electrónica requiere lógica en cliente, por un lado la utilización de Javascript y por otro la necesidad de un ActiveX o un applet (las opciones más habituales), ya que, también por motivos de seguridad, mediante Javascript no tendrías nunca permisos para acceder, por ejemplo, al almacén de certificados.

El punto de verificación 6.3 de las Pautas de Accesibilidad de la WAI (que como hemos dicho deben acatar las aplicaciones de las Administraciones Públicas) dice así:

"Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible".

Dicho punto es de Prioridad 1, es decir, es necesario para alcanzar un nivel de adecuación Simple A, el menos exigente (recordemos que hemos dicho que el nivel mínimo recomendado era la Doble A, el siguiente nivel de adecuación y más exigente que la Simple A).

La WAI es realista, prevé que en aquellos casos en los cuales la tecnología del momento no alcanza para ofrecer la plena accesibilidad de un servicio, no habrá más solución que ofrecer una versión o un modo de interacción diferente. En este caso habría que ofrecer una alternativa accesible para los usuarios cuyo navegador no admite o no tiene activo el Javascript (según W3C el 10% de los usuarios navegan con el Javascript desactivado), así como para aquellos que no puedan ejecutar el ActiveX o el applet.

Podría pensarse en una alternativa como la que estamos habituados en los entornos de banca, después de informar al usuario de que su navegador no admite Javascript o no lo tiene activado, o que si bien admite Javascript no puede ejecutar los componentes cliente de firma electrónica (ActiveX o Applet) y que por tanto no podrá autenticarse o firmar con certificado digital, informarle como digo de que sí que podrá hacerlo mediante usuario y contraseña, reforzado por ejemplo con una tarjeta de coordenadas, incluso disponible en versión braille como la que ofrece Bankinter a sus clientes.

El problema es que, aunque esta solución podría valernos para la autenticación, en el caso de la firma electrónica, dentro de la Administración Pública no tendría validez legal, puesto que se exige que la firma electrónica ofrezca garantías de Autenticación, Integridad y No repudio, lo que le confiere validez legal. [5] .

Por tanto, nos encontramos con una paradoja: la Administración Pública debe ofrecer servicios de tramitación telemática que necesitan de firma electrónica, pero a su vez debe cumplir con las Pautas de Accesibilidad de la WAI. Y ambos son incompatibles hoy en día. Podrán hacerse accesibles todos los contenidos salvo aquellos que requieran firma electrónica.

A este respecto, la web del Ministerio de Fomento, en su apartado de Accesibilidad dice así:

“Todas las aplicaciones satisfacen todos los puntos de verificación de prioridad 1 y 2 definidos en las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0) por la Iniciativa de Accesibilidad Web (WAI) del World Wide Web Consortium (W3C). De acuerdo a lo anterior, ninguna de las aplicaciones necesita para alcanzar su funcionalidad completa el uso de javascript.

En el caso de que la complejidad de los formularios haya aconsejado mantener funcionalidades que hagan uso de javascript para mejorar su usabilidad, se ofrece una versión accesible AA alternativa y equivalente.

No obstante es necesario puntualizar lo siguiente: Por motivos de seguridad es necesario que las operaciones de firma se realicen en su navegador, por lo que éste debe capaz de ejecutar javascript y los componentes cliente de firma electrónica (ActiveX o Applet). Ésta es la única excepción a la norma y la única funcionalidad que emplee javascript que usted se encontrará si elige usar la versión accesible AA de las aplicaciones.”

Paradójico, como digo: podrás realizar todo el proceso pero no te servirá de nada, porque al final no podrás firmar, deberás cerrar el ordenador e irte a hacer cola a una ventanilla.

La tecnología Web debe avanzar, así que si os queréis forrar ya sabéis lo que tenéis que patentar: una forma de realizar firma electrónica accesible, sin necesidad de lógica en cliente. Hoy en día suena a ciencia ficción, ya veremos mañana.

NOTAS

[1] Ley 34/2002, en su Disposición Adicional Quinta.

Las Administraciones públicas adoptarán las medidas necesarias para que la información disponible en sus respectivas páginas de Internet pueda ser accesible a personas con discapacidad y de edad avanzada, de acuerdo con los criterios de accesibilidad al contenido generalmente reconocidos, antes del 31 de diciembre de 2005.

[2] Por ejemplo, en el marco concreto de los registros y las notificaciones telemáticas, los "Criterios de seguridad, normalización y conservación de las aplicaciones utilizadas para el ejercicio de potestades" (Criterios SNC)”. Indica en su apartado cinco específicamente la Doble A:

La Orden PRE/1551/2003, de 10 junio, por la que se desarrolla la Disposición final primera del Real Decreto 209/2003, de 21de febrero de 2003, que regula los registros y las notificaciones telemáticas, así como la utilización de medios telemáticos para la sustitución de certificados por los ciudadanos, establece que el registro telemático y el servicio de notificación telemática deberán cumplir los requerimientos en materia de accesibilidad establecidos por la Iniciativa para una Web Accesible (WAI) del Consorcio World Wide Web y en particular las especificaciones de la Recomendación de 5 de mayo de 1999 sobre Pautas de Accesibilidad del Contenido en la Web, versión 1.0, en su nivel AA.
[…]
5.2 Los servicios electrónicos puestos por la Administración a disposición del ciudadano deben ser visualizables, accesibles y funcionalmente operables desde diversos navegadores alternativos. En particular, se deben adaptar las aplicaciones web a los estándares del World Wide Web Consortium (W3C), evitar la utilización de extensiones propietarias de navegadores y verificar el sitio web, al menos, con http://validator.w3.org/. (Véase capítulo 'Software libre y de fuentes abiertas')

[3] Por ejemplo en la Resolución del Parlamento Europeo sobre la Comunicación de la Comisión “eEurope 2002: Accesibilidad de los sitios Web públicos y de su contenido (COM(2001) 529 – C5 – 0074/2002 – 2002/2032(COS) de abril de 2002,” en su punto 30:

Subraya que para que los sitios web sean accesibles es fundamental que satisfagan el nivel doble A y que se aplique en su totalidad la prioridad 2 de las Pautas WAI.

[4] El artículo 45 de la Ley 30/1992, impone a las Administraciones Públicas la obligación de impulsar el empleo y aplicación de técnicas electrónicas, informáticas y telemáticas en el desarrollo de su actividad y el ejercicio de sus competencias. Esta tarea de promoción recibió un nuevo impulso legislativo con la reforma operada por la Ley 24/2001.

[Más información]

[5] Ley 59/2003, de 19 de septiembre, de firma electrónica.

Usable y accesible

Descripción extensa de una imagen: accesible con lector de pantalla y visible sin imágenes activas

HTML

CSS

JS

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

HIJAX

Enlaces que actúan como botones. Implementación accesible.

Quiero hacer esto

¿Qué nos podemos encontrar?

¿Por qué ninguna de estas opciones es accesible?

¿Cuál es entonces la solución?

AJAX Accesible (II): WAI-ARIA

Cuál es el problema

Cuál es la solución: WAI-ARIA

En qué consiste la solución

Tabindex

Roles

Estados y propiedades

En resumen:

¿Puedo aplicar WAI-ARIA a cualquier página HTML o XHTML?

¿Los navegadores y AT ya soportan WAI-ARIA?

Ejemplos

Enlaces de interés

Ejemplos

Utilidades

Generales

Artículos

Formulario con varios botones. Implementación usable y accesible

Implementar la acción por Javascript

Varios formularios

Alternativa accesible con <noscript>

¿Y si utilizamos las etiquetas <a> o <button>?

XForm

MVC

AJAX accesible

AJAX no es un fin, es un medio

AJAX con sentido común

AJAX y navegadores

AJAX accesible

¿Cómo podemos pues ofrecer alternativas accesibles para los desarrollos AJAX sin crear dos aplicaciones diferentes?

Es necesario conocer...

En resumen, buenas prácticas

Notas

Accesibilidad, firma electrónica y DNIe en el ámbito de las Administraciones Públicas

Alternativa accesible con `<noscript>`

¿Y si utilizamos las etiquetas `<a>` o `<button>`?