El propósito del presente artículo no es otro que el introducir un debate respecto a diferentes aspectos interrelacionados en el desarrollo web, tratando de diferenciar entre contenido web y aplicaciones web, como base para entender las pautas, normas y leyes que regulan la accesibilidad.

Para ello comenzaré por hacer una distinción entre: usabilidad y accesibilidad, para después reflexionar sobre la seguridad en entornos web y el cumplimiento de pautas y/o normas de accesibilidad.

La Usabilidad mide lo fácil que puede llegar a ser el usar un tipo de producto y qué tipo de satisfacción quedará remanente en el usuario. El crear una página web con estas características es fundamental, ya que al contrario que otros productos, la vida de una página web para un usuario es tan efímera como un click. Una buena página web tiene que provocar el interés del usuario por los contenidos ofertados. De otro modo, aún con buenos contenidos la mayoría de los usuarios escaparán del sitio.

La Accesibilidad se centra más en lo difícil que es acceder a los contenidos ofrecidos. Es obvio que los dos factores se encuentran unidos por un nexo importante. De este modo una página puede ser usable y no accesible. Por ejemplo, si una página hace un uso abusivo de imágenes, la página puede ser bastante usable pero si por un momento las imágenes no se cargan o el acceso lo hace una persona discapacitada, un lector de pantalla no podrá describir el contenido de la página.

Ambos conceptos se implementan en un contexto web por las recomendaciones de la Iniciativa de Accesibilidad Web (WAI), en su versión 2.0 (WCAG 2.0), si bien las certificaciones vigentes al respecto, como la UNE 139803:2004 siguen basándose en las WCAG 1.0. Teniendo en cuenta que dichas primeras recomendaciones cuentan con diez años de vida (última revisión del 5 de mayo de 1999), es fácil entender que precisaran una actualización, siendo uno de sus hándicaps principales la implementación de la seguridad en el sitio web versus la accesibilidad del mismo. Por tal motivo, parece que un escenario adecuado sea la transición de uno a otro; en el cual se analicen las soluciones aportadas por las recomendaciones 2.0, que salvan las problemáticas de seguridad (o pueden aportar otras nuevas) que impedían (según la UNE 139803:2004) la certificación de alcances que incluyeran, por ejemplo:

-          Combo-box de validación. (Ejemplo: Portal web de www.cajastur.es)

-          Sistemas que impliquen firma electrónica.

-          Etc.

Sobre firma electrónica 

No debe confundirse el acceso a aplicaciones web por firma electrónica con autenticación por medio de certificado. Podemos acceder (login) a una aplicación web con nuestro certificado, y que sea accesible. En lo que se refiere a la firma electrónica en una aplicación web, hay sin embargo una serie de conceptos claros. El proceso técnico es, más o menos, como el que sigue:

1.   El usuario introduce los datos que debe firmar. Esto puede ser de muchas formas; rellenar un formulario HTML, adjuntar un fichero, etc.

2.   El navegador del usuario debe generar un resumen (digest) con un algoritmo hash (tipo MD5 o SHA-1) de la información a firmar.

3.   El navegador debe utilizar la clave privada del certificado digital del cliente para cifrar esta información. Este cifrado es asimétrico; lo que se cifra con la clave privada podrá ser descifrado con la clave pública, y sólo con esta. Para realizar esta operación, el navegador debe consultar de alguna forma el almacén de certificados del cliente, hacerle escoger el certificado con el que quiere firmar, y utilizar la clave privada almacenada en el certificado escogido para cifrar ese hash. Ya tenemos la firma: es el hash cifrado.

4.   El navegador envía al servidor de firma todos los datos necesarios: el hash cifrado y la clave pública del certificado digital del cliente. Ahora éste lo almacena con el formato que se considere más oportuno. En cualquier momento se puede verificar la validez de esa firma con una sencilla operación: descifrando la firma con la clave pública del certificado, y comparándola con el resultado de realizar el hash, almacenar el documento original con su firma (el hash cifrado). De esta forma, si algún día se quiere comprobar que lo que introdujo el usuario (el documento original) no ha sido modificado maliciosamente (lo que le confiere validez legal), se puede realizar una sencilla operación de comprobación de firma, consistente en descifrar la firma con la clave pública del certificado digital, obteniendo el hash, y aplicando el algoritmo de hash sobre el documento original. Si ambos hash coinciden, la firma es válida.

El problema es que los pasos 2 y 3 deben realizarse en cliente, es decir, en el navegador. Esto es totalmente necesario y obligatorio; precisamente, uno de los puntos clave para mantener la seguridad del proceso se basa en que la clave privada del certificado del cliente nunca sale de la máquina del cliente. Hay un número finito de tecnologías para ejecutar esto en un navegador web: lo más normal son applets Java o clientes Active X, invocados desde Javascript. De hecho, éste es uno de los puntos claves para que un trámite telemático sea lo más universal y usable posible: la calidad del componente cliente.

Sobre la accesibilidad web 

En lo que se refiere a la accesibilidad web, las pautas 1.0 del WAI te exigen que para acceder a tu contenido web no sea imprescindible el uso de applets o javascript. En concreto, la pauta 6.3 dice que “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”.

Según esta pauta entendemos que no podemos tener una calificación AA de accesibilidad si utilizamos javascript y applets, ya que deberíamos tener una página alternativa. El problema es que no podemos tener una página alternativa ya que la operación que realizamos no se puede realizar de otra forma de manera legal.

Sobre las Administraciones Públicas 

Por último, las Administraciones Públicas exigen por regla general que sus portales web, incluyendo sus oficinas virtuales, alcancen un nivel AA de accesibilidad, esto es, cumplan todos los puntos de verificación de prioridad 1 y 2.

Pero también exigen que para que una operación telemática sea legal, se haga utilizando firma electrónica que, como hemos visto, tiene problemas insalvables de accesibilidad; porque hoy por hoy no es posible firmar sin ejecutar lógica de cliente que no todos los navegadores o dispositivos de usuario tienen por qué soportar. Por ello, la alternativa legal que podemos dar a nuestra web con firma electrónica es que el usuario se vaya a la institución físicamente.

¿No es un contrasentido? Se piden dos cosas incompatibles entre sí.

Una conclusión: quedarse en medio.

Bajo mi punto de vista, no debemos olvidar que las pautas 1.0 del WAI se refieren al acceso al contenido. Una Oficina Virtual, por ejemplo, está mucho más cerca de una aplicación web que de un portal, por lo que debe plantearse si las pautas aplican con la misma restrictividad. En todo caso, siempre se puede tratar de que toda la web sea accesible realmente, y sacar la zona dotada de firma electrónica de la declaración de accesibilidad. Y esperar a que la tecnología avance para superar estos escollos.