Vídeos sobre accesibilidad web

Tres vídeos de un seminario sobre la accesibilidad web. El contenido está bien, pero el sonido es muy malo.

Legibilidad de una página web

En ¿Tu Sitio es Entendible y Fácil de Leer? nos presentan la herramienta TxReadability (versión en español) que evalúa la facilidad de lectura de una página web, para textos en español, inglés y japonés.

El W3C, en la pauta 14 de sus Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:

Pauta 14. Asegúrese de que los documentos sean claros y simples.

Asegure que los documentos son claros y simples para que puedan ser más fácilmente comprendidos.

La maquetación coherente de páginas, los gráficos reconocibles y el lenguaje fácilmente comprensible benefician a todos los usuarios. En particular, ayudan a personas con discapacidades cognitivas o con dificultades en la lectura. (Por tanto, asegúrese de que las imágenes tienen textos equivalentes para los ciegos, los de baja visión o para cualquier usuario que no puede o ha elegido no ver los gráficos. Consulte también la pauta 1).

La utilización de un lenguaje claro y simple promueve una comunicación efectiva. El acceso a la información escrita puede ser difícil para personas con discapacidades cognitivas o de aprendizaje. La utilización de un lenguaje claro y simple también beneficia a las personas cuyo primer idioma es diferente al del autor, incluidos aquellos que se comunican principalmente mediante lengua de signos.

Puntos de verificación:

14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]
Técnicas para el punto de verificación 14.1.

14.2 Complemente el texto con presentaciones gráficas o auditivas cuando ello facilite la comprensión de la página. [Prioridad 3]
Consultar también la pauta 1.
Técnicas para el punto de verificación 14.2.

14.3 Cree un estilo de presentación que sea coherente para todas las páginas. [Prioridad 3]
Técnicas para el punto de verificación 14.3.

Esta herramienta nos puede ayudar a cumplir esta pauta.

Nuevo borrador de WCAG 2.0

Con fecha 11/12/07 se ha publicado un nuevo borrador de las Web Content Accessibility Guidelines 2.0. La fecha límite para enviar comentarios es el 01/02/08. ¿Para cuándo la recomendación definitiva?

En la entrada ¿Qué pasa con WCAG 2.0? comenté los problemas que está teniendo esta nueva recomendación.

JavaScript no molesto (5): validación de formularios

En la entrada JavaScript no molesto (4): separación del JavaScript se explicó cómo aprovechar el atributo class para separar el código JavaScript del código XHTML. En esta entrada se va a explicar cómo utilizar la misma técnica para validar formularios.

Los formularios se deben validar en el navegador por varias razones, las más importantes son:

• Disminuye el tiempo de respuesta de la aplicación: el usuario no tiene que esperar a que se envíen los datos al servidor, se validen en el servidor y se reciba una respuesta para saber si los datos están bien o están mal.
• Se reduce la carga de trabajo del servidor (no del todo, como ahora se explicará): en el servidor no se tienen que validar los formularios de todos los usuarios, en el navegador de cada usuario se validan los datos que ha introducido.

La segunda razón no es verdad en parte, porque SIEMPRE hay que validar los datos que se reciben en el servidor, ya que un usuario malicioso los puede enviar directamente, sin pasar antes por la validación de nuestro formulario. Por tanto, la solución que vamos a ver para separar el JavaScript del XHTML no supone un problema cuando no se dispone de JavaScript, ya que los datos serán validados en el servidor.

Sí que puede haber problemas cuando se emplea JavaScript para actualizar un control del formulario o una página web en función de las acciones del usuario. Por ejemplo, el típico caso de las listas desplegables en cascada (una lista que muestra sus valores en función de lo que se ha elegido en otra lista) realizado con JavaScript no funcionaría si está desactivado. Este problema es distinto al que se explica en esta entrada y merece una para él solo.

Consejo 1: no se debe usar botones de tipo button con el evento onclick para enviar un formulario

El código siguiente presenta un grave problema de accesibilidad: cuando JavaScript no está disponible, el formulario no se puede enviar.

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<input type="button" value="Enviar" onclick="validar()">Para solucionar este problema, se deben emplear los botones de tipo submit y utilizar el evento onsubmit para llamar al código de validación:

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<form action="unapagina.php" onsubmit="return validar()"></form>Consejo 2: utiliza múltiples clases para indicar el tipo de validación que requiere cada control de un formulario

En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:

• Utilizar campos ocultos (hidden) para indicar las validaciones que se tienen que realizar (valor requerido, correo electrónico, código postal).
• Utilizar el atributo class para indicar el tipo de validación.
• Crear un DTD propio para añadir atributos que indican el tipo de validación.

La primera opción es poco práctica, ya que no es adecuada para formularios complejos con muchos campos. La tercera opción tampoco es práctica, ya que una página web basada en un DTD propio no es una página válida respecto a XHTML. Por tanto, la opción más recomendable es la segunda.

En el class se pueden añadir valores para indicar el tipo de validación que requiere el control:

• required
• notrequired
• email
• integer
• date

Por ejemplo:

<input type="text" name="correo" class="required email">
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:

• A Guide to Unobtrusive JavaScript Validation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)

III Premios TAW 2007

He encontrado esta noticia en el periódico El País: Los portales del Ministerio de Fomento y Ayuntamiento de Madrid los más accesibles. TAW ya ha otorgado sus premios anuales a las páginas web más accesibles. En la página Los portales del Ministerio de Fomento y Ayuntamiento de Madrid ganan los III Premios TAW a las web públicas más accesibles podemos encontrar la nota de prensa de TAW y en la página Premiados 2007 la lista de premiados que reproduzco:

Reunido el jurado para la concesión de los III Premios TAW a la Accesibilidad Web, el día 15 de Noviembre de 2007 en la sede de la Fundación CTIC, resuelven conceder los premios por categorías a:
T.1. Premio TAW a la Web pública más Accesible I.
GANADOR: Sitio web Ministerio de Fomento
Finalista: Sitio web Ministerio de Cultura
Finalista: Sitio web Autoridad Administrativa CITES
T.2. Premio TAW a la Web pública más Accesible II.
GANADOR: Sitio Web Ayuntamiento de Madrid
Finalista: Sitio web Ayuntamiento de Ermua
Finalista: Sitio web Ayuntamiento de Murcia
T.3. Premio TAW a la Web Empresarial más Accesible I.
GANADOR: Sitio web Cajastur
Finalista: Sitio web Gamesa
Finalista: Sitio web Babel Sistemas de información
T.4. Premio TAW a la Web Empresarial más Accesible II.
GANADOR: Sitio web Cafetto Kaldi
Finalista: Sitio web Serviweb S.L.
Finalista: Sitio web Gateway S.C.S.
T.5. Premio TAW a la Web de entidades sin ánimo de lucro más Accesible.
GANADOR: Sitio web Aspaym Cantabria
Finalista: Sitio web Asociación Síndrome Prader-Willi
Finalista: Sitio web Fundación Estudios e Análises
T.6. Premio TAW al Mejor Proyecto en Accesibilidad Web.
El jurado declara desierta esta categoría.

Facilidades para el acceso a la administración electrónica

He encontrado esta noticia en el periódico El Mundo: El acceso a la administración electrónica para los discapacitados, más fácil. La noticia dice:

Las personas con discapacidad podrán acceder a la administración electrónica con mayor facilidad, gracias a la firma de un convenio firmado entre la Fundación ONCE y la Fundación Europea para la Sociedad de la Información y la Administración Electrónica.

El convenio, entre otros puntos, incluye el desarrollo de una herramienta informática para permitir el uso de todos los programas del Servicio Administratel a las personas con discapacidad, incluyendo aquellas que poseen una discapacidad visual severa.

¿Qué es Administratel? Pues no lo sé, pero esta es la página web de Administratel.

Esquinas redondeadas

Las esquinas redondeadas, como las que se pueden ver en esta misma página, son un estilo visual muy empleado por su vistosidad. Sin embargo, tienen varios problemas de los que me gustaría destacar dos:

• Se suelen basar en el empleo de imágenes, lo que origina un aumento en el peso de la página (aumenta el tiempo de carga) y origina problemas de mantenimiento (por ejemplo, si se desea cambiar los colores hay que cambiar las imágenes).
• Al utilizar imágenes puede ocasionar problemas de accesibilidad o, al menos, molestar a los usuarios que empleen un lector de pantallas.

Acabo de encontrar Esquinas redondeadas sin emplear imágenes: sólo CSS y JavaScript. Se trata de una traducción de la página Nifty Corners Cube. Desde estas páginas nos podemos descargar un script en JavaScript que permite tener esquinas redondeadas (y algunas cosas más) sin tener que utilizar imágenes. Y si JavaScript no está disponible, no pasa nada, las esquinas salen cuadradas pero la página se ve bien.


Un ejemplo de página que usa este script:



¿Cómo se consigue? En Nifty Corners: rounded corners without images (la primera versión de este script) se explica el truco.

Lector de pantalla para teléfonos móviles

He encontrado esta noticia en el periódico El Mundo: 'Mobile Speak', una aplicación para personas ciegas que lee la pantalla del móvil. Según dice, es el primer lector de pantalla para teléfono móvil que se lanza en el mercado español. Parece que sólo está disponible para el sistema Symbian y supongo que también permitirá navegar con los navegadores integrados en los teléfonos móviles.

Control cerebral del ordenador

He encontrado esta noticia en el periódico El Mundo: Los discapacitados motrices podrían jugar en el mundo virtual de Second Life. La noticia nos cuenta que en la Universidad Keio de Japón (la misma que junto con el MIT y el INRIA fundaron el W3C a mediados de los noventa) están experimentando con un sistema que consiste en unos electrodos que se conectan al cuero cabelludo del usuario y le permite moverse por Second Life simplemente con el pensamiento.

Esta técnica se conoce como control cerebral o control neural. Evidentemente, no se tiene que limitar exclusivamente a Second Life, se puede emplear para cualquier otra tarea, como por ejemplo navegar por Internet.

Hay más gente que está trabajando en este tema e incluso ya hay algunas empresas que venden estos dispositivos, aunque por ahora no son muy precisos y requieren de un entrenamiento previo largo (que el ordenador aprenda a interpretar las señales que emite el cerebro). Algunso artículos sobre el tema:

• Control cerebral
• Casco de 'ondas cerebrales' controla un ordenador
• El reto del control remoto neural

JavaScript no molesto (4): separación del JavaScript

La entrada de ayer terminaba con la pregunta ¿No se puede separar el código JavaScript del código HTML como se hace con CSS?

Sí, sí que se puede. Una página web se puede construir mediante capas:

• Capa de contenido: la estructura y el contenido con etiquetas de XHTML.
• Capa de presentación: la presentación del contenido definida con CSS.
• Capa de comportamiento: el comportamiento del contenido (por ejemplo, la respuesta ante una acción del usuario) definido con JavaScript.

Con un diseño basado en capas logramos reducir el acomplamiento entre los distintos componentes (contenido, presentación y comportamiento), lo que se traduce en importantes beneficios: disminución de los errores, reducción en los costes de mantenimiento, etc. Pero además, una página web construida de esta forma (que se conoce como progressive enhancement) casi siempre es graceful degradation, y por tanto la página web funcionará correctamente aun en el caso de que falte algún tipo de componente (CSS o JavaScript).

¿Cómo se puede lograr esto? En el código HTML no vamos a escribir ni una sola línea de código JavaScript. Más aun, tampoco se van a emplear los manejadores de eventos como onclick, onblur, etc.

Desde JavaScript, se puede asignar código de JavaScript a un manejador de eventos con el siguiente código:

elemento.evento = acccion;

Para seleccionar un elemento de la página web (una celda en una tabla, un botón en un formulario, un enlace, etc.) se puede emplear:

• getElementById(id): selecciona el emento indicado por el id.
• Usar una combinación de getElementsByTagName(etiqueta) y getAttribute(atributo) para seleccionar elementos con un atributo específico.

En la entrada JavaScript no molesto (3): las ventanas emergentes se puso como ejemplo los enlaces que se abren en ventanas emergentes. Para indicar que un enlace es de este tipo, vamos a añadir al atributo class un valor que no se emplea en el CSS, pero que desde CSS nos va a permitir saber que se trata de una ventana emergente:

<a href="http://www.ua.es/" class="estilo popup">Universidad de Alicante</a>
En el atributo class, el valor estilo se emplea en el CSS para asignar una presentación concreta, mientas que el atributo popup se emplea en JavaScript para identificar los enlaces que se tienen que abrir en ventanas emergentes:

window.onload = prepareLinks;
function prepareLinks() {
  var links = document.getElementsByTagName("a");
  for (var i=0; i= 0) {
      links[i].onclick = function() {
        popUp(this.getAttribute("href"));
        return false;
      }
    }
  }

}

function popUp(winURL) {
  window.open(winURL,"popup","width=320,height=480");
}

En el código anterior se realizan los siguientes pasos:

1. Se asigna al evento onload la función prepareLinks: esta función será llamada automáticamente cuando la página termine de cargarse.
2. La función prepareLinks obtiene un array con todos los enlaces de la página web.
3. Para cada enlace, se comprueba si el atributo class contiene el valor popup.
4. Si el enlace está marcado como popup, le asigna una función de JavaScript al evento onclick.

Para más información sobre cómo lograr la separación del código JavaScript:

• DHTML no intrusivo
• Nociones básicas de JavaScript no intrusivo
• Behavioral Separation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)
• 7 reglas de oro para hacer un javascript no obstructivo

JavaScript no molesto (3): las ventanas emergentes

Una ventana emergente (popup window) es una ventana independiente del navegador que se abre de forma automática (por ejemplo, las molestas ventanas emergentes de publicidad que se abren al cargar una página) o de forma manual como respuesta a una acción del usuario de una página (por ejemplo, al pulsar sobre un enlace).

En el caso de estas últimas, lo normal es que se abran tras pulsar el usuario sobre un enlace o un botón. El uso de botones con el evento onclick se debería evitar, ya que supone una barrera de accesibilidad en el caso de que JavaScript no esté disponible. Por tanto, nos vamos a centrar en las ventanas emergentes activadas al pulsar sobre un enlace.

En el href de un enlace se puede utilizar directamente JavaScript. Por ejemplo, suponiendo que tenemos la función popUp que abre una ventana emergente:

function popUp(winURL) {
window.open(winURL,"popup","width=320,height=480");
}

simplemente tenemos que escribir javascript:popUp('http://www.ua.es/') en la dirección del enlace. También se puede emplear el evento onclick y dejar la dirección en blanco o poner el símbolo "#":

<a href="" onclick="popUp('http://www.ua.es/');">UA</a>Cualquiera de las dos posibilidades impide que los usuarios sin JavaScript puedan acceder al contenido indicado.

La solución es muy sencilla:

• Añadir en el enlace una URL al contenido que se desea visualizar.
• En el código JavaScript, añadir return false; al final para evitar que se ejecute el enlace cuando se ejecute el código JavaScript. La URL del enlace indicada con href sólo será empleada cuando JavaScript no esté disponible.

Con esta solución, la funcionalidad se ve reducida para los usuarios sin JavaScript porque no se abre en una nueva ventana, pero no falla completamente.

La solución anterior se puede mejorar para evitar el tener que repetir la URL tanto en el enlace como en el evento onclick:

<a href="http://www.ua.es/" onclick="popUp(this.getAttribute('href')); return false;">UA</a>o también:

<a href="http://www.ua.es/" onclick="popUp(this.href); return false;">UA</a>Pero esta solución aún se puede mejorar más, ya que el código JavaScript está escrito directamente en las etiquetas HTML, lo cual ocasiona algunos problemas:

• Dificulta la escritura.
• Dificulta la lectura.
• Dificulta el mantenimiento.

¿No se puede separar el código JavaScript del código HTML como se hace con CSS?

Uso de la propiedad float de CSS

El uso de la propiedad float de CSS es un poco confuso. Si se hacen pruebas sin haber leído antes una explicación sobre cómo se usa es difícil sacar conclusiones. Pero esta propiedad es muy importante si se quiere lograr un diseño (layout) de una página web que sea válido para diferentes resoluciones de pantalla.

En la sección 9.5 Floats de Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification podemos encontrar la explicación oficial de esta propiedad. Pero para aprender a usar la propiedad float, es mucho mejor consultar Floatutorial. Este tutorial ofrece explicaciones muy claras sobre el uso de este atributo y termina explicando como se puede utilizar para lograr un diseño a 2 columnas o a 3 columnas líquido (que se adapte a diferentes resoluciones de pantalla).

Página con muchos recursos

Acabo de encontrar la página web Web Design References: Accessibility. Es una página web muy buena, ya que contiene multitud de enlaces a páginas web donde explican temas relacionados con la accesibilidad. Los temas que contiene son:

• Abbreviations & Acronyms
• Accessibility Statements
• Accesskeys
• Alt Attributes , Alt Text, Long Descriptions
• Assistive Technology
• Baseline
• Benefits (Why accessibility?)
• Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart)
• Checklists
• Cognitive Disabilities
• Definitions and Overviews
• Device Independence and Graceful Degradation
• Deprecated Features
• Flicker
• Forms
• Language
• Law, Lawsuits, Policies
• Lists
• Mailto
• Multimedia
• Open Source
• Plugins, PDF, PowerPoint, etc.
• Relative sizing
• Scripts
• Structure & Semantics
• Style Sheets (Accessibility)
• Tables
• Testing, Checking, Validating
• Text Links
• Text Only Versions
• Usability and Accessibility
• Zoom Layouts
• Articles & Related Links

Libro electrónico: Access by Design Online

Gracias a Gabriel Porras y su página Libros Gratis he encontrado el libro Access by Design Online. No está en formato PDF para descargar, sólo está en formato HTML para consultarlo en línea.

El libro está estructurado a modo de catálogo de consejos con múltiples ejemplos de páginas web reales. Incluye consejos sobre el HTML que se debe utilizar para cumplir el consejo, pero no incluye ejemplos completos de código, por lo que en algunos casos se queda corto de contenido y será necesario consultar otras fuentes para entender cómo se hace.

Ya encajan "casi" todas las piezas de la accesibilidad de las páginas web en España

En los últimos días, con la aprobación del RD 1494/2007 se ha aclarado una cuestión que para muchos era un misterio y que es muy importante: ¿qué nivel de accesibilidad debe tener una página web en España? Por ahora, las páginas web de las empresas no están obligadas a alcanzar ningún nivel, pero las páginas web de las Administraciones públicas ya no tienen excusa.

¿Por qué es necesario este reglamento si ya existía la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico (LSSI)?

Recordemos lo que dice esta ley:

Disposición adicional quinta. Accesibilidad para las personas con discapacidad y de edad avanzada a la información proporcionada por medios electrónicos.

Uno. 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.
Asimismo, podrán exigir que las páginas de Internet cuyo diseño o mantenimiento financien apliquen los criterios de accesibilidad antes mencionados.

Pero también dice:

Disposición final séptima. Habilitación al Gobierno.
Se habilita al Gobierno para desarrollar mediante Reglamento lo previsto en esta Ley.

La LSSI no establece el nivel de accesibilidad que deben cumplir las páginas web a las que se refiere (páginas web de las Administraciones públicas y páginas web financiadas por las Administraciones públicas). Casi todo el mundo entendió que la frase "de acuerdo con los criterios de accesibilidad al contenido generalmente reconocidos" indicaba que al no definir un nivel el Gobierno de España, se aplicaría lo indicado por la Unión Europea, es decir, el nivel AA del WAI del W3C. Pero una ley no puede (o no debería) dejar abiertas las puertas a diferentes interpretaciones.

Como aclara Gabriel Porras, el reglamento del RD 1494/2007 desarrolla la LSSI, define mediante la norma UNE 139803:2004 el nivel de accesibilidad que se debe alcanzar y establece un calendario para ello. Pero este calendario entra en contradicción con lo establecido en la LSSI, ya que sobrepasa la fecha del 31/12/2005 que se fijó en la LSSI.

¿Por qué la norma UNE 139803:2004 si tenemos las WCAG 1.0 del WAI?

Fran Tarifa nos aclara el misterio. Según una cita del presidente de la Fundación SIDAR, Loïc Martínez Normand:

[...] parece ser que en España no se puede referenciar en la legislación a documentos técnicos que no provengan de organismos oficiales de normalización (como AENOR, CEN e ISO) y, por desgracia, el W3C no lo es.

Es decir, que la norma UNE, que es una copia de las pautas del WAI, es un medio para referirse a las WCAG 1.0 y que tenga validez legal en España.

Trabajo en un ayuntamiento (diputación, instituto, universidad, etc.). ¿Qué pasa si no cumplo el reglamento?

Pues no lo sé. Se supone que en algún momento existirá un regimen sancionador. Hace unos días publiqué el comentario Sanciones por discriminar a discapacitados donde comenté que el Congreso debatía una ley que establece sanciones de hasta un millón de euros por discriminar a discapacitados. En concreto, la noticia decía:

El proyecto de ley considera infracciones administrativas las discriminaciones directas o indirectas, acosos, así como el incumplimiento de las exigencias de accesibilidad las que están sometidas las entidades.

Dentro de esta explicación se puede incluir la accesibilidad de las páginas web. Pero por el resto de la noticia parece que esta nueva ley se refiere a las empresas y no a las Administraciones públicas.

Mitos sobre la accesibilidad

He encontrado la página web Mitos y Conceptos Erróneos sobre la Accesibilidad. Es una traducción de la página web Accessibility myths and misconceptions. En este artículo se desmontan una serie de mitos que existen sobre la accesibilidad web. La lista de mitos es:

1. La accesibilidad es sólo para personas ciegas.
2. Los sitios accesibles son feos y aburridos.
3. La accesibilidad es costosa y difícil.
4. Ofrecer una versión sólo texto es suficiente.
5. Personalización y la funcionalidad de lectura en voz alta.

JavaScript no molesto (2): cómo desactivar JavaScript

Antes de analizar algunas técnicas para conseguir que JavaScript "no moleste" en la página, vamos a ver cómo desactivar el intérprete de JavaScript en los navegadores más comunes. De esta forma, podremos comprobar si una página que contiene código JavaScript sigue siendo funcional y accesible cuando el código JavaScript no se ejecuta.

En Microsoft Internet Explorer 7, en el menú Herramientas --> Opciones de Internet --> Seguridad --> Nivel personalizado... se abre el cuadro de diálogo Configuración de seguridad; en la categoría Automatización (Scripting) hay que deshabilitar la opción Active scripting, tal como podemos ver en la siguiente imagen:

En Microsoft Internet Explorer también es interesante desactivar la opción Scripting de applets de Java.

En Mozilla Firefox 2.0, en el menú Herramientas --> Opciones --> Contenido tenemos que desactivar la opción Activar JavaScript que podemos ver en la siguiente imagen:

En Opera 9 hay dos formas de desactivar JavaScript:

• Menú Herramientas --> Opciones más a mano --> Activar JavaScript
• Menú Herramientas --> Opciones --> Avanzado --> Activar JavaScript, como podemos observar en la siguiente imagen.

Entradas anteriores:

• JavaScript no molesto (1): Definición

Norma UNE 139803:2004

En la entrada de ayer Aprobado reglamento sobre condiciones básicas de accesibilidad comenté que el reglamento aprobado establece que la Norma UNE 139803:2004 regula el nivel de accesibilidad de las páginas web en España.

Esta norma antes era de pago y estaba prohibida su reproducción sin el consentimiento de AENOR. Ahora ya se puede descargar de forma gratuita desde Norma UNE 139803:2004.

JavaScript no molesto (1): Definición

El término JavaScript no molesto es la traducción del inglés unobtrusive JavaScript. En muchas páginas (por ejemplo, en la Wikipedia) aparece mal traducido como JavaScript no obstructivo o no intrusivo. Ni obstructivo ni intrusivo existen en el Diccionario de la lengua española de la Real Academia Española, por lo que no se deben usar. Unobtrusive se traduce al español como discreto o no molesto.

La Wikipedia contiene la definición de JavaScript no obstructivo:

JavaScript no obstructivo es un paradigma floreciente en el uso del lenguaje de programación JavaScript, utilizado en la Web. Aunque el término no se define formalmente, sus principios generalmente incluyen:

• Separación de la funcionalidad JavaScript (la "capa del comportamiento") de las capas de estructura/contenido y de presentación de un página.
• Uso de buenas prácticas a fin de evitar los problemas de incompatibilidad de la programación tradicional en JavaScript (tales como inconsistencias entre navegadores y falta de escalabilidad).

El objetivo final es que las páginas web sean totalmente funcionales para aquellos usuarios que no puedan o no quieran hacer uso de JavaScript.

Cuando escribí sobre Hijax: Ajax accesible ya comenté que esta técnica se basa en lo que se conoce en inglés como progressive enhancement y graceful degradation, dos estrategias que permiten que un sistema informático (en este caso, una página web) funcione correctamente aun en el caso de que falte algún tipo de componente. Mientras que con progressive enhancement se parte de una versión básica completamente operativa (se parte de una página web compatible con la mayoría de los navegadores y con el menor uso posible de tecnologías complementarias como CSS o JavaScript), con graceful degradation se parte del extremo contrario: se crea una página web para los últimos navegadores, con la posibilidad de que funcione en navegadores antiguos.

¿Hay gente que navega por Internet y su navegador no admite JavaScript? En la página Browser Statistics podemos ver que en enero de 2007 había un 6% de usuarios sin JavaScript.

Pero los beneficios no son sólo para los posibles visitantes de nuestro sitio web: nosotros mismos nos beneficiaremos al tener separados la estructura de la página (HTML), la presentación (CSS) y la lógica (JavaScript). Los costes de mantenimiento de una página web son menores si lo tenemos todo bien separado y en su sitio.

¿Qué se tiene que hacer para tener JavaScript no molesto? En próximas entradas comentaré algunas de las técnicas más comunes. Recomiendo la lectura de la página Javascript no obstructivo, Manual de buenas maneras, que ofrece una extensa explicación del tema.

Aprobado reglamento sobre condiciones básicas de accesibilidad

Hoy se ha publicado en el BOE el REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social.

El reglamento cubre diferentes medios de comunicación, como son la televisión, las telecomunicaciones y las páginas web. Respecto estas últimas, llamadas "páginas de internet", el Artículo 5. Criterios de accesibilidad aplicables a las páginas de internet de las administraciones públicas o con financiación pública dice:

1. La información disponible en las páginas de internet de las administraciones públicas deberá ser accesible a las personas mayores y personas con discapacidad, con un nivel mínimo de accesibilidad que cumpla las prioridades 1 y 2 de la Norma UNE 139803:2004.
Esta obligación no será aplicable cuando una información, funcionalidad o servicio no presente una alternativa tecnológica económicamente razonable y proporcionada que permita su accesibilidad.
Asimismo, respecto a la lengua de signos, las citadas páginas de internet tendrán en cuenta lo dispuesto en la Ley 27/2007, de 23 de octubre, por la que se reconocen las lenguas de signos españolas y se regulan los medios de apoyo a la comunicación oral de las personas sordas, con discapacidad auditiva y sordociegas.

2. Excepcionalmente, las administraciones públicas podrán reconocer la accesibilidad de páginas de internet conforme a normas técnicas distintas de las que figuran en el apartado 1 de este artículo, siempre que se compruebe que alcanzan una accesibilidad similar a la que estas normas garantizan.

3. Las páginas de Internet de las administraciones públicas deberán contener de forma clara la información sobre el grado de accesibilidad al contenido de las mismas que hayan aplicado, así como la fecha en que se hizo la revisión del nivel de accesibilidad expresado.

[...]

Respecto a los plazos para el cumplimiento de este reglamento, la Disposición transitoria única. Plazos establece:

2. Las páginas de internet de las administraciones públicas o con financiación pública deberán adaptarse a lo dispuesto en el artículo 5 de dicho reglamento, en los siguientes plazos:
a) Las páginas nuevas deberán ajustarse a la prioridad 1 de la Norma UNE 139803:2004 desde la entrada en vigor del real decreto.
b) Las páginas existentes deberán adaptarse a la prioridad 1 de la Norma UNE 139803:2004 en el plazo de 6 meses desde la entrada en vigor.
c) Todas las páginas, actualmente existentes o de nueva creación, deberán cumplir la prioridad 2 de la Norma UNE 139803:2004 a partir del 31 de diciembre de 2008.
No obstante, este plazo de adaptación y la citada norma técnica de referencia podrán ser modificados a efectos de su actualización mediante orden ministerial conjunta, en los términos establecidos en la disposición final tercera de este real decreto.

En resumen:

• Los niveles de la Norma UNE 139803:2004 equivalen prácticamente a los niveles de las WCAG del W3C.
• Las nuevas páginas web se tienen que ajustar al nivel 1 desde la entrada en vigor del reglamento (el día siguiente al de su publicación en el BOE, es decir, 22/11/2007).
• Las páginas web existentes se tienen que adaptar al nivel 1 en el plazo de 6 meses (22/05/2008).
• Todas las páginas tienen que cumplir el nivel 2 a partir del 31/12/2008.

¿Por qué una norma UNE propia y no las del W3C? ¿Quién va a realizar las certificaciones? En la página Medidas en materia de accesibilidad a servicios de la Sociedad de la Información en España se aclaran algunas confusiones que pueden existir al respecto de esta normativa.