Contenido dinamico en javascript válido con WCAG2.0
Julio Camarero
hace tiempo que sigo el blog de Olga y también los mensajes de este
grupo y agradezco mucho toda la información que se está dando para
facilitar la adaptación de nuestros sitios web a WCAG2.0
Actualmente estoy trabajando en una librería open-source de
componentes javascript (www.alloyui.com) que forma parte del framework
del portal open source Liferay (www.liferay.com). Actualmente estamos
intentando que la próxima versión del portal valide nivel AA de
WCAG2.0 (http://www.liferay.com/web/julio.camarero/blog/-/blogs/in-our-
way-to-wcag-2-0%3A-accessibility-improvements-episode-1) pero nos
hemos encontrado un problema bastante grande con la inserción de
contenido dinámicamente usando javascript (por ejemplo, al pinchar en
un botón con un menú desplegable o un pop-up modal en una página).
El objetivo de poner aquí nuestro problema era averiguar si alguien se
ha encontrado ya con el mismo problema y ha llegado a una solución o
si es una limitación técnica de WCAG2.0 que no podremos cumplir hasta
que madure la tecnología.
Siguiendo la técnica SCR26 del WCAG2.0:
http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html#SCR26
Inserting dynamic content into the Document Object Model immediately
following its trigger element, deberíamos insertar el contenido
dinámico en el DOM a continuación del elemento que lo lanza (por
ejemplo, si es un pop-up modal, a continuación en el DOM del botón que
hace que aparezca).
El problema que nos hemos encontrado al desarrollar nuestros
componentes javascript accesibles que utilizan contenido dinámico (un
botón con menú desplegable o un pop-up modal) es que si alguno de los
padres contenedores del elemento que los contiene tiene la propiedad
css overflow:hidden y position:relative, puede que el elemento no se
visualice correctamente. Hemos creado una demo para mostrar este
problema aqui: http://www.alloyui.org/deploy/tests/a11y/ (esperar a
que desparezca el mensaje de loading para probarlo). Sé que la
solución en nuestro ejemplo es quitar el overflow hidden o la position
relative, pero como nosotros estamos generando una librería de
componentes javascript no podemos garantizar que el usuario que use
nuestra librería no tenga estas propiedades en algún div contenedor de
nuestro componente.
La solución (compatible con todos los navegadores) que hemos
encontrado es mover el contenido dinámico al final del <body> para así
evitar cualquier problema con el css de los contenedores existentes.
(Podéis ver en la demo que funciona bien), pero el problema que tiene
es que se rompe la navegación por teclado y los screen readers no lo
encontrarán. (Además de que ya no cumpliríamos la técnica SCR26)
Nos gustaría saber si alguien se ha enfrentado ya a este problema y ha
encontrado alguna forma de solucionar esto cumpliendo con WCAG2.0, o
si quizás la solución sea ir manipulando el focus a nuestros elementos
para que se mantenga la navegación por teclado y los screen readers lo
lean y utilizar ARIA.
un saludo y muchas gracias,
Julio Camarero
Liferay España
Jorge Soriano Aguilera - Mr. Soriano
Yo no tengo problemas con la visualización de ese pop-up modal. ¿A qué problemas te refieres?
Saludos
--
Jorge Soriano Aguilera
Diseño gráfico y desarrollo web
mrsoriano.com - cor...@mrsoriano.com
Julio Camarero
--
Has recibido este mensaje porque estás suscrito al grupo "Usable y Accesible" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a usable-y-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a usable-y-accesi...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/usable-y-accesible?hl=es.
Julio Camarero
respuesta por si a otras personas les puede ser útil o para seguir la
discusión:
Hola Julio.
Para el problema que comentas yo utilicé la solución del foco que
comentas, ya que el soporte de ARIA todavía no es mayoritario.
Los pasos fueron:
- Usar un tabindex negativo para la capa de la ventana modal
(tabindex=-1)
Ese atributo tabindex se ha de asignar con javascript, ya que sólo
con javascript habilitado podremos usarlo.
El tabindex negativo evita que la capa esté en el orden natural de
navegación de la página, es decir, no entorpece la navegación.
- Al clicar el enlace que abre esa capa, le doy el foco mediante
capa.focus() ya que una vez que la capa tiene el atributo tabindex es
posible darle el foco mediante javascript.
- Al cerrar la capa devuelvo el foco al enlace que la abrió.
Espero haberte ayudado.
Saludos.
On Feb 18, 11:19 am, Julio Camarero <juliocamar...@gmail.com> wrote:
> Hola Jorge,
>
> para probar el efecto explicado en la demo debes seguir estos pasos:
>
> 1. Haz click en el botón "Open dialog". El pop-up se abre correctamente
> porque ninguno de los divs que lo contienen tienen position:relative
> overflow:hidden
>
> 2. Haz click en el botón "Turn on position relative & overflow hidden". Esto
> hará que el contenedor del botón que abre el pop-up tenga estas propiedades
> css.
>
> 3. Haz click de nuevo en "Open dialog" y verás que el pop-up no se visualiza
> correctamente.
>
> El problema con estas propiedades css es que son muy comunes y es muy
> probable que cualquier usuario creando un sitio web y que vaya a utilizar
> nuestros componentes las haya utilizado en algún contenedor del botón que
> muestra el pop-up. De ahí que nuestra solución fuera mover el html del
> pop-up al final del body para evitar cualquier problema de solapamiento y
> mostrarlo siempre, pero esta solución choca directamente con WCAG2.0.
>
> un saludo y gracias por echarle un ojo,
>
> Julio
>
> 2010/2/18 Jorge Soriano Aguilera - Mr. Soriano <mambrudes...@gmail.com>
>
>
>
> > HOla Javier,
>
> > Yo no tengo problemas con la visualización de ese pop-up modal. ¿A qué
> > problemas te refieres?
>
> > Saludos
>
> > --
> > Jorge Soriano Aguilera
> > Diseño gráfico y desarrollo web
> > mrsoriano.com - cor...@mrsoriano.com
>
> > --
> > Has recibido este mensaje porque estás suscrito al grupo "Usable y
> > Accesible" de Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > usable-y-...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > usable-y-accesi...@googlegroups.com<usable-y-accesible%2Bunsubs cr...@googlegroups.com>