A la hora de desarrollar páginas web avanzadas, muchos de nosotros nos hemos hemos tenido que enfrentar al problema de la accesibilidad. Casi siempre, en ese camino, nos hemos encontrado con la disyuntiva de la usabilidad frente a la accesibilidad. Inevitablemente nos hacemos esta pregunta ¿Hacer páginas web accesibles está reñido con la usabilidad?

Quizás la anterior pregunta sería muy larga de analizar y posiblemente cada uno de nosotros, según nuestras propias experiencias, tengamos una respuesta. Sin embargo, en este artículo vamos a centrarnos en una cuestión un tanto más específica, pero muy relacionada con la anterior: ¿Qué puedo hacer para continuar usando Javascript y sin embargo la web sea accesible?

La realidad, a la hora de hacer un desarrollo web , nos lleva a entender que hacer un site accesible no es complicado, siempre que se sigan unas normas estrictas de diseño e implementación. Pero, cuando además se quiere dotar al proyecto de una buena experiencia de usuario, la cosa cambia.

Hasta ahora hemos visto equipos de desarrollo que realizan dos portales , uno accesible y otro no accesible, de tal manera que según se activa o desactiva el Javascript la web va redirigiendo a una versión u a otra. Para nosotros esta solución tiene una gran desventaja, además de la necesidad de duplicar nuestro volumen de trabajo, pues dicha alternativa conlleva el mantenimiento de dos portales en paralelo, lo que puede crear incongruencias. Aunque tiene la ventaja de que la página es plenamente funcional y es plenamente accesible.

La otra solución es la de poner etiquetas noscript y dotar de esa funcionalidad a la web…

La solución que hoy proponemos trata de unir las etiquetas noscript con una nueva técnica que combina el Ajax y métodos de página, para poder detectar si está o no activo el motor Javascript en el navegador del usuario.

En lo primero que podemos pensar es en utilizar el objeto Request.Browser.JavaScript, sin embargo, esto trae problemas ya que solo dice si el navegador lo admite , pero no nos dice si está activo (además de que ese objeto está en desuso y acceder a él nos arrojará un bonito Warning).

El código (en c#) de la solución propuesta es el siguiente:

public static bool JavascriptActivo { get; set; }
#region Eventos del formulario
protected void Page_Load(object sender, EventArgs e)
{
JavascriptActivo = false;

}

#endregion

[WebMethod]
public static void TieneJavascript()
{
JavascriptActivo = true;
}

Por su parte, en el aspx tendríamos que utilizar el siguiente código:

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="True">
</asp:ScriptManager>

<script language="javascript" type="text/javascript">
PageMethods.TieneJavascript();
</script>

Con esto le estamos diciendo que queremos utilizar el método de página “TieneJavaScript”, el cual activa la propiedad estática que define si utiliza Javascript. Y por último, en cada postback le decimos que la ponga a false (que no utiliza Javascript). En realidad, el poner esta propiedad a false es para detectar si mantiene activo el Javascript.

La explicación es sencilla, según el ciclo de vida primero se ejecuta el onload, y luego se renderiza la página, es entonces cuando se ejecuta el Javascript, que está funcionando por Ajax, y por lo tanto no realiza refresco de la página.

Si utiliza Javascript se hace la llamada al método de página y todo transcurre como se espera, si no, simplemente se actualiza la variable y se muestra la página sin Javascript.

Conclusión:

El 28 de diciembre del 2007 se publicó la Ley de Medidas de Impulso de la Sociedad de la Información. En la misma se obliga a los entes públicos a la eliminación de barreras de accesibilidad de sus sitios. Esta es la razón principal por la que todo desarrollador, debe aprender las reglas para realizar sus desarrollos web de forma accesible. Entre estas normas destacamos la imposibilidad de ejecución de Javascript, o mejor dicho, la necesidad de crear una opción mediante la cual se pueda hacer lo mismo que se implementa con Javascript, pero con programación a través del servidor.

Hasta ahora las medidas que se han tomado, pasaban por la duplicidad de código, redirigiendo a páginas accesibles y dejando el portal no accesible a disposición de usuarios sin limitaciones.

En nuestra solución damos un remedio a los inconvenientes de la situación anterior, ya que al ejecutar el script a descargase la página detectamos en las primeras fases si se esta ejecutando o no, y en sucesivos postback estaremos seguros de cual es la situación actual de navegador.

Si a eso le sumamos que por defecto el estado del Javascript del navegador cliente será estable nos da un maravilloso juego de probar una vez (en la página de inicio) y guardar dicho estado en la session de usuario.

Todo esto nos lleva a una amplia gama de posibilidades, pero siempre con la ventaja de no tener que duplicar el códigoS