accesskey_mod_content

Objetos programados

  • Escuchar
  • Imprimir PDF
  • Compartir

Para la operación con certificados electrónicos dentro de una Sede electrónica se debe utilizar tecnología de ejecución dinámica, de mayor potencia que el lenguaje (X)HTML estándar. Dicha tecnología consiste en la utilización de scripts y aplicación de una lógica de cliente basada en applets, objetos ActiveX u otros elementos que puedan ser ejecutados en el ordenador personal del usuario en el momento de la operación con el certificado.

Para cumplir con las WCAG 1.0, este empleo de objetos programados ejecutados en el navegador del usuario chocaba directamente con el requisito de accesibilidad que exigía que las páginas debían poder utilizarse aunque los scripts y objetos de programación estuviesen desconectados o no fuesen soportados. Se consideraba una barrera tecnológica que no era posible superar, dado que no hay forma de leer las claves de un usuario prescindiendo de este tipo de tecnologías. Por tanto, esta limitación tecnológica se trataba como una excepción y no se consideraba un obstáculo para que la Sede electrónica fuese finalmente accesible.

En cambio, bajo los nuevos requisitos de las WCAG 2.0, esto deja de ser un problema y no tiene por qué tratarse como una excepción. En la nueva normativa se permite el uso de tecnologías y elementos de programación, sin necesidad de que se siga proporcionando la misma funcionalidad cuando no se soporte dicha tecnología, siempre que la misma se emplee de forma compatible con la accesibilidad.

Se entiende que una tecnología (por ejemplo, scripts, applets, etc.) es compatible con la accesibilidad si con la misma es posible crear contenido accesible y los navegadores y productos de apoyo (p. ej. lectores de pantalla) de uso común son compatibles con dicha tecnología o, si es necesario un plugin, éste está disponible para su descarga o compra con la misma facilidad y precio para las personas con discapacidad como para una persona sin discapacidad.

 

Sí. La tecnología JavaScript se puede utilizar siempre y cuando se haga de forma no intrusiva y accesible. Es decir, JavaScript se puede usar siempre que el contenido generado y/o modificado, así como las funcionalidades añadidas, sean compatibles con los productos de apoyo como los lectores de pantalla. Así, por ejemplo, el contenido generado debe ser accesible, se debe preservar siempre el orden de lectura del contenido y todos los elementos de interacción deben ser accesibles con teclado en el orden de tabulación correcto. 

En caso de que se emplee JavaScript para crear funcionalidades e interfaces de usuarios complejas se deben emplear las pautas indicadas en la especificación de WAI-ARIA (Abre en nueva ventana) del W3C para añadir la capa de accesibilidad necesaria para asegurar su compatibilidad con los productos de apoyo.

Para ampliar información se recomienda consultar la especificación de WAI-ARIA así como también el documento introductorio WAI-ARIA Primer.

De forma general se puede decir que una aplicación GIS se podrá hacer accesible cuando la funcionalidad principal subyacente de dicha aplicación puede ser operable con teclado y la información proporcionada se puede dar en formato de texto.

Sin embargo, en algunos casos puede que no exista una alternativa tecnológica económicamente razonable y proporcionada que permita su accesibilidad. Por lo tanto, es una de las posibles excepciones contempladas por el Real Decreto 1494/2007 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(Abre en nueva ventana) , en su artículo 5 apartado 1.

Así, por ejemplo, un buscador de sitios de interés cercanos puede emplear un mapa como parte del interfaz para ubicar visualmente los resultados y dar información detallada sobre los mismos mediante marcadores y ventanas de información. La funcionalidad subyacente (informar sobre los sitios de interés cercanos) se puede realizar de forma accesible con un formulario y un listado de resultados, con su correspondiente detalle, ordenados por proximidad y mostrado de forma conjunta a la visualización del mapa. Algo similar a la funcionalidad "Cómo llegar" de Google Maps donde se introduce el origen y el destino en campos de texto y se proporciona el resultado tanto en un mapa como en forma de texto.

Por el contrario, otras aplicaciones GIS complejas pueden considerarse como excepciones si su funcionalidad principal subyacente requiere forzosamente de la interacción mediante un dispositivo de apuntamiento (p. ej. ratón) y/o la naturaleza de la información mostrada no permite su textualización de forma técnicamente viable. Este tipo de aplicaciones están relacionadas generalmente con zonas geográficas, áreas o espacios con gran densidad de información como pueden ser mapas cartográficos, callejeros de ciudades, planos, visualizaciones en 3D, etc.

Por ejemplo, y de forma concreta, la búsqueda de datos y referencias catastrales se puede hacer accesible mediante un formulario (aunque se acompañe de visualizaciones en un mapa) mientras que la consulta directa de la cartográfica catastral presenta limitaciones técnicas para su implementación de forma accesible.

En todo caso, e independientemente de la imposibilidad de ofrecer alternativas textuales para la información mostrada, siempre que sea técnicamente posible se ha de cumplir el resto de requisitos de accesibilidad para permitir el acceso al mayor número posible de personas independientemente de su tipo o grado de discapacidad. Así, aunque una aplicación GIS no disponga de alternativas textuales, puede seguir cumpliendo otros requisitos como interfaz independiente de dispositivo, redimensión del texto, etiquetado de los controles, orden de tabulación, información no dependiente del color, contraste suficiente, etc., de forma que no se impida el acceso a personas con otro tipo de discapacidades como las motrices, daltonismo, baja visión, etc.

Lo primero es crear la página en (x)HTML incluyendo todo el texto en ella, sin scripts. El texto que se quiera desplegar se incluye dentro de un elemento asignándole un id concreto.

Por otra parte se creará un enlace, mediante técnicas JavaScript y DOM, que sea el que muestre y oculte el texto. A dicho enlace se le asigna un evento onclick asociado a la función JavaScript de desplegar el texto.

Ejemplo de código HTML
  • Presentación  
    • Quiénes somos 
    • Contacta con nosotros
  • Descarga de documentación  
    • Formularios 
    • Impresos

Mediante JavaScript y DOM se deberá acceder a los elementos “Presentación” y “Descarga de documentación”, y se crean los enlaces con un evento onclick.

En las hojas de estilo se crean dos estilos, uno para el texto oculto y otro para el texto cuando se muestre desplegado.

Ejemplo de código CSS
 ul.oculto {
 position:absolute;
 left:-9999px;
 overflow:hidden;
}

ul.desplegado {
 font-style:italic;
}

 

Se utiliza además una función JavaScript que pliega o despliega el texto, cambiándole la clase al elemento HTML que se le indica como parámetro.

Ejemplo de código JavaScript
 /* Función para plegar o desplegar texto */
function plegar(texto) {
  var elemento = document.getElementById(texto);
  if (elemento.className == "desplegado") {
  elemento.className = "oculto";
  } else {
  elemento.className = "desplegado";
  }
}

 

Y por último otro JavaScript para ocultar el texto cuando se carga la página por primera vez, de forma que al usuario que disponga de JavaScript se le muestre el menú plegado, y al que no tenga soporte para esta tecnología se le muestre completo. Este script se situará al final de la página web.

Ejemplo de código JavaScript
 /* Script que plegará todos los textos que se le indiquen */
plegar(’desplegable1’);
plegar(’desplegable2’);