Hola, Iván y todos.

No voy a entrar en el resto de la accesibilidad de Lightbox, porque no
lo he testeado demasiado y no sé hasta qué punto es accesible en otros
terrenos, pero desde luego en lo que respecta al uso de atributos ARIA,
yo te diría que no debes preocuparte.

Estrictamente hablando, es cierto que no se cumple la validación de
HTML, pero teniendo en cuenta que esos atributos son para dotar de más
accesibilidad al sitio, dudo mucho que ninguna auditoría seria los
marque como errores del punto 3.2 (si lo hacen, deberías indicarles que
son para esto, y sería absurdo que te prohibieran su uso). El punto
relativo a la validación lo que pretende es que el código esté bien
formado, que las anidaciones estén bien, que no haya ID duplicados,
etc., y así se entendió en WCAG 2.0, donde la validación no es tan
estricta como en la primera versión de las pautas.

Por cierto, que en cuanto a lo que comentas del uso de AJAX, lógicamente
este AJAX tendrá que ser accesible directamente con las ayudas técnicas
(puntos 6.2, 6.5 y 8.1), accesible con teclado (6.4 y 9.3), que a falta
de estilos la página se siga entendiendo bien (6.1), y que sin scripts
no se pierdan funcionalidades básicas (6.3). ¡Suerte! (guiño)

Saludos,
Ramón.

Iván escribió:
> Estoy comenzando a desarrollando un portal que deberá cumplir con la norma UNE
139803:2004 y tengo la duda de si permitirá o no incluir efectos como lightbox,
concretamente jQuery Accessible Lightbox (
http://wiki.github.com/fnagel/jQuery-Accessible-RIA/lightbox ).
>

Señor José María Ortiz

Cordial saludo

Observá en
este<http://cuencodigital.com/videos/galerias_de_imagenes_en_drupal.html>
enlace
como crear una galería de imágenes en Drupal. allí utilizan varios módulos
que te pueden ilustrar como hacerlo, aparte de otras alternativas para crear
galería de imágenes. espero te sirva de ayuda.

Atte. Edgar Correa


[Se han eliminado los trozos de este mensaje que no contenían texto]

Hola, muchas gracias por la información, pero trabajo con lector de pantalla
y por desgracia no puedo acceder al video, no me detecta los controles y no
encuentro la manera de reproducirlo.

Un saludo.



   _____

De: accesoweb@yahoogroups.com [mailto:accesoweb@yahoogroups.com] En nombre
de Edgar Correa Escobar
Enviado el: lunes, 15 de marzo de 2010 14:44
Para: accesoweb@yahoogroups.com
Asunto: [AccesoWeb] OF topic: problemas con galerías de imágenes y lectores
de pantalla en Drupal




Señor José María Ortiz

Cordial saludo

Observá en este<http://cuencodigita
<http://cuencodigital.com/videos/galerias_de_imagenes_en_drupal.html>
l.com/videos/galerias_de_imagenes_en_drupal.html>
enlace
como crear una galería de imágenes en Drupal. allí utilizan varios módulos
que te pueden ilustrar como hacerlo, aparte de otras alternativas para crear
galería de imágenes. espero te sirva de ayuda.

Atte. Edgar Correa

[Se han eliminado los trozos de este mensaje que no contenían texto]






[Se han eliminado los trozos de este mensaje que no contenían texto]

Muchas gracias Ramón, creo que tienes razón, a veces marcar una opción por
defecto en los select, botones de radio o checkbox puede causar problemas y
confusiones para algunos usuarios.

   Gracias de nuevo y un saludo,
   Elena.

   ----- Original Message -----
   From: Ramón Corominas
   To: accesoweb@yahoogroups.com
   Sent: Monday, March 15, 2010 11:35 AM
   Subject: Re: [AccesoWeb] Punto de verificación 10.4



   Hola, Elena y todos.

   Algunas aclaraciones y puntos de vista distintos...

   1. Textos incluidos en campos de texto

   Aunque pueden ayudar a usuarios de navegadores antiguos, los textos por
   defecto en los campos de edición pueden resultar tremendamente confusos
   para los usuarios de lector de pantalla. En la mayor parte de las
   ocasiones, el lector de pantalla NO LEE ese texto, sino tan sólo la
   etiqueta del control. Esto puede producir que el usuario entre en el
   campo y teclee, sin saberlo, a continuación del texto que ya estaba ahí,
   lo que provoca datos erróneos, errores al buscar, etc. Ese es un
   problema bastante serio que, desde mi punto de vista, hace que el punto
   10.4 sea anti-accesibilidad. Sobre todo, teniendo en cuenta que si los
   controles están bien etiquetados, los lectores de pantalla los leen
   siempre, y si tienen borde, etc., se vean correctamente.

   Una posible solución "accesible" sería inyectar estos textos mediante
   javascript, e igualmente borrarlos mediante javascript al recibir el
   foco. Para los usuarios con discapacidad cognitiva, se puede usar un
   etiquetado correcto, un atributo title, o un ejemplo adyacente al campo.

   2. Opciones por defecto en select y botones de radio

   Que yo sepa, no hay ninguna referencia explícita en ninguna de las
   pautas a que estos controles deban tener valores por defecto.
   Personalmente considero que puede ser bastante "peligroso" el marcar
   estos valores por defecto. Si el usuario debe escoger una opción, lo
   normal es que se validen los datos y se advierta al usuario de que hay
   un error, tal y como indican las pautas WCAG 2.0 en el criterio 3.3.2,
   pero no veo una buena idea asumir un valor por defecto. Por ejemplo, el
   usuario podría pasar inadvertidamente una opción seleccionada por
   defecto que diga que es "hombre", o que su fecha de nacimiento es una
   determinada, y esos datos se almacenarían cmoo correctos, cuando lo
   normal es que el usuario hubiera tenido que seleccionarlos. Mi
   recomendación es que se deje en blanco y se efectúe una validación, que
   puede ser mixta de cliente y de servidor (la de servidor es
   obligatoria), e informar de los posibles errores, y tal vez de posibles
   valores (criterios 3.3.2 y 3.3.3 en WCAG 2.0).

   3. Valor por defecto para checkbox de "Acepto las condiciones..."

   Al igual que en el caso anterior, este es aún más peligroso. Se supone
   que esa casilla es un mecanismo de control y verificación de que el
   usuario realmente ha leído y comprende las condiciones que está
   aceptando (criterio 3.3.4 en WCAG 2.0). Si nosotros marcamos esa casilla
   por defecto, no estamos "ahorrando tiempo", sino provocando un problema
   de fiabilidad de que, efectivamente, el usuario ha decidido aceptar las
   condiciones.

   Para terminar, creo que las WCAG 2.0 son bastante más eficientes
   manejando los formularios, y los puntos 3.3.x son mucho más útiles y
   claros que sus correspndientes de las WCAG 1.0. Aunque eso sí, para HTML
   el punto 12.4 de WCAG 1.0 (asociación explícita de etiquetas) debería
   seguir siendo obligatoriomás o menos se corresponde de algún modo con el
   3.3.1 de WCAG 2.0).

   Saludos,
   Ramón.

   > valores por defecto en formularios




[Se han eliminado los trozos de este mensaje que no contenían texto]

Hola Elena y Ramón:



La cuestión de marcar el primer elemento radio de una lista de opciones de
selección no es opinable. Debe hacerse siempre.



Para obtener un documento accesible no basta con leer el documento de las
WCAG y limitarse a su letra. Hay otros documentos relacionados que son
imprescindibles. Por ejemplo, el de la especificación del lenguaje de marcas
que se está usando.



En este caso concreto, la razón por la que debemos marcar SIEMPRE un
elemento input de una serie de botones de tipo radio, viene explicada en la
especificación de HTML 4.01:



[CITA]

Note. Since existing implementations handle this case differently, the
current specification differs from RFC 1866 ([RFC1866]
<http://www.w3.org/TR/html401/references.html#ref-RFC1866>  section
8.1.2.4), which states:

At all times, exactly one of the radio buttons in a set is checked. If none
of the <INPUT> elements of a set of radio buttons specifies `CHECKED', then
the user agent must check the first radio button of the set initially.

Since user agent behavior differs, authors should ensure that in each set of
radio buttons that one is initially "on".

[FIN CITA]

Y como decía en mi mensaje anterior, el deber de dejar seleccionada por
defecto una de las opciones ofrecidas mediante botones de tipo radio, no es
sólo cuestión de accesibilidad sino también de usabilidad. Cito aquí al muy
querido por algunos Jakob Nielsen:

[cita]

·  Always offer a default selection for radio button lists. By definition,
radio buttons always have exactly one option selected, and you therefore
shouldn't display them without a default selection. (Checkboxes, in
contrast, often default to having none of the options selected.)

* If users might need to refrain from making a selection, you should
provide a radio button for this choice, such as one labeled "None." Offering
users an explicit, neutral option to click is better than requiring the
implicit act of not selecting from the list, especially because doing the
latter violates the rule of always having exactly one option chosen.

[fin cita]

Espero que esto aclare esta cuestión, una vez más pues suele salir de tanto
en tanto en esta lista.

Saludos,

Emmanuelle



De: accesoweb@yahoogroups.com [mailto:accesoweb@yahoogroups.com] En nombre
de Elena Sáez
Enviado el: martes, 16 de marzo de 2010 8:34
Para: accesoweb@yahoogroups.com
Asunto: Re: [AccesoWeb] Punto de verificación 10.4





Muchas gracias Ramón, creo que tienes razón, a veces marcar una opción por
defecto en los select, botones de radio o checkbox puede causar problemas y
confusiones para algunos usuarios.

Gracias de nuevo y un saludo,
Elena.

----- Original Message -----
From: Ramón Corominas
To: accesoweb@yahoogroups.com <mailto:accesoweb%40yahoogroups.com>
Sent: Monday, March 15, 2010 11:35 AM
Subject: Re: [AccesoWeb] Punto de verificación 10.4

Hola, Elena y todos.

Algunas aclaraciones y puntos de vista distintos...

1. Textos incluidos en campos de texto

Aunque pueden ayudar a usuarios de navegadores antiguos, los textos por
defecto en los campos de edición pueden resultar tremendamente confusos
para los usuarios de lector de pantalla. En la mayor parte de las
ocasiones, el lector de pantalla NO LEE ese texto, sino tan sólo la
etiqueta del control. Esto puede producir que el usuario entre en el
campo y teclee, sin saberlo, a continuación del texto que ya estaba ahí,
lo que provoca datos erróneos, errores al buscar, etc. Ese es un
problema bastante serio que, desde mi punto de vista, hace que el punto
10.4 sea anti-accesibilidad. Sobre todo, teniendo en cuenta que si los
controles están bien etiquetados, los lectores de pantalla los leen
siempre, y si tienen borde, etc., se vean correctamente.

Una posible solución "accesible" sería inyectar estos textos mediante
javascript, e igualmente borrarlos mediante javascript al recibir el
foco. Para los usuarios con discapacidad cognitiva, se puede usar un
etiquetado correcto, un atributo title, o un ejemplo adyacente al campo.

2. Opciones por defecto en select y botones de radio

Que yo sepa, no hay ninguna referencia explícita en ninguna de las
pautas a que estos controles deban tener valores por defecto.
Personalmente considero que puede ser bastante "peligroso" el marcar
estos valores por defecto. Si el usuario debe escoger una opción, lo
normal es que se validen los datos y se advierta al usuario de que hay
un error, tal y como indican las pautas WCAG 2.0 en el criterio 3.3.2,
pero no veo una buena idea asumir un valor por defecto. Por ejemplo, el
usuario podría pasar inadvertidamente una opción seleccionada por
defecto que diga que es "hombre", o que su fecha de nacimiento es una
determinada, y esos datos se almacenarían cmoo correctos, cuando lo
normal es que el usuario hubiera tenido que seleccionarlos. Mi
recomendación es que se deje en blanco y se efectúe una validación, que
puede ser mixta de cliente y de servidor (la de servidor es
obligatoria), e informar de los posibles errores, y tal vez de posibles
valores (criterios 3.3.2 y 3.3.3 en WCAG 2.0).

3. Valor por defecto para checkbox de "Acepto las condiciones..."

Al igual que en el caso anterior, este es aún más peligroso. Se supone
que esa casilla es un mecanismo de control y verificación de que el
usuario realmente ha leído y comprende las condiciones que está
aceptando (criterio 3.3.4 en WCAG 2.0). Si nosotros marcamos esa casilla
por defecto, no estamos "ahorrando tiempo", sino provocando un problema
de fiabilidad de que, efectivamente, el usuario ha decidido aceptar las
condiciones.

Para terminar, creo que las WCAG 2.0 son bastante más eficientes
manejando los formularios, y los puntos 3.3.x son mucho más útiles y
claros que sus correspndientes de las WCAG 1.0. Aunque eso sí, para HTML
el punto 12.4 de WCAG 1.0 (asociación explícita de etiquetas) debería
seguir siendo obligatoriomás o menos se corresponde de algún modo con el
3.3.1 de WCAG 2.0).

Saludos,
Ramón.

> valores por defecto en formularios

[Se han eliminado los trozos de este mensaje que no contenían texto]





[Se han eliminado los trozos de este mensaje que no contenían texto]

Amén. Gracias por la referencia.

Emmanuelle escribió:
> Since user agent behavior differs, authors should ensure that in each
> set of radio buttons that one is initially "on".
>

Hola a todos.

En Colombia, el Icontec (Instituto Colombiano de Normas Técnicas) está
trabajando en la NTC (Norma Técnica Colombiana) en Accesibilidad Web.

Me gustaría que a través de esta lista pudiéramos encontrar luces sobre algunas
dudas que tengo:

1. ¿Hay alguna norma en el mundo que esté basada en las WCAG 2.0?

2. En el vínculo de la página de Normalización del SIDAR encuentro información
sobre la norma UNE en España, según entiendo, pionera en este terreno. ¿Hay
otras normas en español sobre accesibilidad web?

3. La Unión Europea toma las Directrices de Accesibilidad como norma de facto.
¿Qué ventajas tiene tomar las WCAG 2.0 como norma de facto, frente a la
posibilidad de adaptarlas en una norma técnica?

4. En caso de adaptar las WCAG 2.0 y convertirlas en norma, ¿cuál debe ser el
tratamiento de los derechos de autor?

5. Si adaptáramos las WCAG 2.0, qué forma de presentación creen que debe
predominar:

a) Por principios (Perceptible, Operable, Comprensible, Robusto)
b) Por criterios de conformidad (A, AA y AAA)

Muchas gracias por los aportes.


MARIO CARVAJAL
Astrolabio, Colombia

Estimado compañero/a, le informamos por si es de su interes, que todos los
alumnos - de cualquier parte del mundo - que realicen las sesiones formativas
del taller "Archivos, constructores de ciudadania" y que se impartira de forma
online del 13 al 30 de Abril recibiran CONSTANCIA CONJUNTA firmada, sellada y
reconocida por la Universidad Nacional Abierta y a Distancia de Colombia (UNAD)
y la Fundacion Ciencias de la Documentacion de España.

Esta TITULACION DOBLE es uno de los resultados del Convenio Marco firmado entre
ambas instituciones en el año 2009 con el fin de trabajar conjuntamente por una
capacitacion de calidad en las disciplinas relacionadas con las Ciencias de la
Informacion y Documentacion. Con esta titulacion doble, los participantes a
estas sesiones formativas pueden traducir en creditos academicos homologables
dentro de las cadenas de formacion de la UNAD de Colombia, la intensidad horaria
de su participacion en formacion impartida en el Campus Virtual de la Fundacion
Ciencias de la Documentacion de España. Asi el alumno podra tener un horario
flexible y adaptado a sus caracteristicas individuales, que se podra conectar a
cualquier hora del día y desde cualquier lugar.

FECHAS Y COSTOS DE ESTA PRIMERA EDICION
Taller "Archivos, constructores de ciudadania" dividido en 3 sesiones de trabajo
con matricula de 30 Euros por sesion, que podran ser realizadas individualmente
o como un solo bloque (80 euros), bajo el esquema:

- Archivos y Corrupcion. Del 13 al 16 Abril, 10h.
http://www.documentalistas.org/formacion/archivos_corrupcion.php
- Archivos y Tecnologias de la Informacion. Del 20 al 23 Abril, 10h.
http://www.documentalistas.org/formacion/archivos_tecnologias.php
- Archivos y Organismos Internacionales. Del 27 al 30 Abril, 10h.
http://www.documentalistas.org/formacion/archivos_organismos.php

El participar es muy facil, debe seleccionar el o los curso(s) donde desea
matricularse y hacer el pago del mismo por paypal
(http://www.documentalistas.org/paypal/index.php) o si lo desea por WesterUnion
indicando los cursos/talleres de su interes para que le hagamos llegar los datos
del pago por WesterUnion desde su pais.

Quedamos a su disposición, reciba un cordial saludo

---
Dpto. de Informacion
Fundacion Ciencias de la Documentacion
Para estar informado "Boletin Docuforum"
http://www.documentalistas.org/servicios/docuforum.php

Muchas gracias por la aclaración Emmanuelle.

Saludos,
Elena.

   ----- Original Message -----
   From: Emmanuelle Gutiérrez y Restrepo
   To: accesoweb@yahoogroups.com
   Sent: Tuesday, March 16, 2010 11:38 AM
   Subject: RE: [AccesoWeb] Punto de verificación 10.4



   Hola Elena y Ramón:

   La cuestión de marcar el primer elemento radio de una lista de opciones de
   selección no es opinable. Debe hacerse siempre.

   Para obtener un documento accesible no basta con leer el documento de las
   WCAG y limitarse a su letra. Hay otros documentos relacionados que son
   imprescindibles. Por ejemplo, el de la especificación del lenguaje de marcas
   que se está usando.

   En este caso concreto, la razón por la que debemos marcar SIEMPRE un
   elemento input de una serie de botones de tipo radio, viene explicada en la
   especificación de HTML 4.01:

   [CITA]

   Note. Since existing implementations handle this case differently, the
   current specification differs from RFC 1866 ([RFC1866]
   <http://www.w3.org/TR/html401/references.html#ref-RFC1866> section
   8.1.2.4), which states:

   At all times, exactly one of the radio buttons in a set is checked. If none
   of the <INPUT> elements of a set of radio buttons specifies `CHECKED', then
   the user agent must check the first radio button of the set initially.

   Since user agent behavior differs, authors should ensure that in each set of
   radio buttons that one is initially "on".

   [FIN CITA]

   Y como decía en mi mensaje anterior, el deber de dejar seleccionada por
   defecto una de las opciones ofrecidas mediante botones de tipo radio, no es
   sólo cuestión de accesibilidad sino también de usabilidad. Cito aquí al muy
   querido por algunos Jakob Nielsen:

   [cita]

   · Always offer a default selection for radio button lists. By definition,
   radio buttons always have exactly one option selected, and you therefore
   shouldn't display them without a default selection. (Checkboxes, in
   contrast, often default to having none of the options selected.)

   * If users might need to refrain from making a selection, you should
   provide a radio button for this choice, such as one labeled "None." Offering
   users an explicit, neutral option to click is better than requiring the
   implicit act of not selecting from the list, especially because doing the
   latter violates the rule of always having exactly one option chosen.

   [fin cita]

   Espero que esto aclare esta cuestión, una vez más pues suele salir de tanto
   en tanto en esta lista.

   Saludos,

   Emmanuelle

   De: accesoweb@yahoogroups.com [mailto:accesoweb@yahoogroups.com] En nombre
   de Elena Sáez
   Enviado el: martes, 16 de marzo de 2010 8:34
   Para: accesoweb@yahoogroups.com
   Asunto: Re: [AccesoWeb] Punto de verificación 10.4

   Muchas gracias Ramón, creo que tienes razón, a veces marcar una opción por
   defecto en los select, botones de radio o checkbox puede causar problemas y
   confusiones para algunos usuarios.

   Gracias de nuevo y un saludo,
   Elena.

   ----- Original Message -----
   From: Ramón Corominas
   To: accesoweb@yahoogroups.com <mailto:accesoweb%40yahoogroups.com>
   Sent: Monday, March 15, 2010 11:35 AM
   Subject: Re: [AccesoWeb] Punto de verificación 10.4

   Hola, Elena y todos.

   Algunas aclaraciones y puntos de vista distintos...

   1. Textos incluidos en campos de texto

   Aunque pueden ayudar a usuarios de navegadores antiguos, los textos por
   defecto en los campos de edición pueden resultar tremendamente confusos
   para los usuarios de lector de pantalla. En la mayor parte de las
   ocasiones, el lector de pantalla NO LEE ese texto, sino tan sólo la
   etiqueta del control. Esto puede producir que el usuario entre en el
   campo y teclee, sin saberlo, a continuación del texto que ya estaba ahí,
   lo que provoca datos erróneos, errores al buscar, etc. Ese es un
   problema bastante serio que, desde mi punto de vista, hace que el punto
   10.4 sea anti-accesibilidad. Sobre todo, teniendo en cuenta que si los
   controles están bien etiquetados, los lectores de pantalla los leen
   siempre, y si tienen borde, etc., se vean correctamente.

   Una posible solución "accesible" sería inyectar estos textos mediante
   javascript, e igualmente borrarlos mediante javascript al recibir el
   foco. Para los usuarios con discapacidad cognitiva, se puede usar un
   etiquetado correcto, un atributo title, o un ejemplo adyacente al campo.

   2. Opciones por defecto en select y botones de radio

   Que yo sepa, no hay ninguna referencia explícita en ninguna de las
   pautas a que estos controles deban tener valores por defecto.
   Personalmente considero que puede ser bastante "peligroso" el marcar
   estos valores por defecto. Si el usuario debe escoger una opción, lo
   normal es que se validen los datos y se advierta al usuario de que hay
   un error, tal y como indican las pautas WCAG 2.0 en el criterio 3.3.2,
   pero no veo una buena idea asumir un valor por defecto. Por ejemplo, el
   usuario podría pasar inadvertidamente una opción seleccionada por
   defecto que diga que es "hombre", o que su fecha de nacimiento es una
   determinada, y esos datos se almacenarían cmoo correctos, cuando lo
   normal es que el usuario hubiera tenido que seleccionarlos. Mi
   recomendación es que se deje en blanco y se efectúe una validación, que
   puede ser mixta de cliente y de servidor (la de servidor es
   obligatoria), e informar de los posibles errores, y tal vez de posibles
   valores (criterios 3.3.2 y 3.3.3 en WCAG 2.0).

   3. Valor por defecto para checkbox de "Acepto las condiciones..."

   Al igual que en el caso anterior, este es aún más peligroso. Se supone
   que esa casilla es un mecanismo de control y verificación de que el
   usuario realmente ha leído y comprende las condiciones que está
   aceptando (criterio 3.3.4 en WCAG 2.0). Si nosotros marcamos esa casilla
   por defecto, no estamos "ahorrando tiempo", sino provocando un problema
   de fiabilidad de que, efectivamente, el usuario ha decidido aceptar las
   condiciones.

   Para terminar, creo que las WCAG 2.0 son bastante más eficientes
   manejando los formularios, y los puntos 3.3.x son mucho más útiles y
   claros que sus correspndientes de las WCAG 1.0. Aunque eso sí, para HTML
   el punto 12.4 de WCAG 1.0 (asociación explícita de etiquetas) debería
   seguir siendo obligatoriomás o menos se corresponde de algún modo con el
   3.3.1 de WCAG 2.0).

   Saludos,
   Ramón.

   > valores por defecto en formularios

   [Se han eliminado los trozos de este mensaje que no contenían texto]

   [Se han eliminado los trozos de este mensaje que no contenían texto]





[Se han eliminado los trozos de este mensaje que no contenían texto]

Muchas gracias por la respuesta Ramón, ha sido de gran ayuda . Procuraré cumplir
los puntos que me has señalado en los casos con AJAX.

Saludos!

--- En accesoweb@yahoogroups.com, Ramón Corominas <listas@...> escribió:
>
> Hola, Iván y todos.
>
> No voy a entrar en el resto de la accesibilidad de Lightbox, porque no
> lo he testeado demasiado y no sé hasta qué punto es accesible en otros
> terrenos, pero desde luego en lo que respecta al uso de atributos ARIA,
> yo te diría que no debes preocuparte.
>
> Estrictamente hablando, es cierto que no se cumple la validación de
> HTML, pero teniendo en cuenta que esos atributos son para dotar de más
> accesibilidad al sitio, dudo mucho que ninguna auditoría seria los
> marque como errores del punto 3.2 (si lo hacen, deberías indicarles que
> son para esto, y sería absurdo que te prohibieran su uso). El punto
> relativo a la validación lo que pretende es que el código esté bien
> formado, que las anidaciones estén bien, que no haya ID duplicados,
> etc., y así se entendió en WCAG 2.0, donde la validación no es tan
> estricta como en la primera versión de las pautas.
>
> Por cierto, que en cuanto a lo que comentas del uso de AJAX, lógicamente
> este AJAX tendrá que ser accesible directamente con las ayudas técnicas
> (puntos 6.2, 6.5 y 8.1), accesible con teclado (6.4 y 9.3), que a falta
> de estilos la página se siga entendiendo bien (6.1), y que sin scripts
> no se pierdan funcionalidades básicas (6.3). ¡Suerte! (guiño)
>
> Saludos,
> Ramón.
>
> Iván escribió:
> > Estoy comenzando a desarrollando un portal que deberá cumplir con la norma
UNE 139803:2004 y tengo la duda de si permitirá o no incluir efectos como
lightbox, concretamente jQuery Accessible Lightbox (
http://wiki.github.com/fnagel/jQuery-Accessible-RIA/lightbox ).
> >
>

Hola Mario,



Te respondo punto por punto:



1.- ¿Hay alguna norma en el mundo que esté basada en las WCAG 2.0?  No, por
el momento no hay ninguna norma basada en la versión 2.0 de las WCAG.



2.- En el vínculo de la página de Normalización del SIDAR encuentro
información sobre la norma UNE en España, según entiendo, pionera en este
terreno. ¿Hay otras normas en español sobre accesibilidad web? No, aunque
por diversas vías he intentado conseguir una norma panamericana, aún no lo
he logrado.



3.- La Unión Europea toma las Directrices de Accesibilidad como norma de
facto. ¿Qué ventajas tiene tomar las WCAG 2.0 como norma de facto, frente a
la posibilidad de adaptarlas en una norma técnica? La principal ventaja es
no tener que redactar una nueva norma cada vez que se actualice el documento
de las WCAG. Una norma técnica sigue un proceso muy específico que hace que
sea necesario bastante tiempo hasta que puede llegar a ser publicada y,
además, debe cumplir con ciertos requisitos en su redacción. La versión 2.0
de las WCAG se redactó con la intención, precisamente, de que fuese lo más
directamente convertible en norma técnica, pero lamentablemente ese objetivo
no se ha conseguido. De acuerdo con la legislación de muchos países, es
necesario contar con una norma técnica y no es posible en una ley hacer
referencia a un documento de una entidad no normativa, como es el caso del
W3C. Esa es la razón por la que en muchos casos es imprescindible crear esa
norma técnica, aunque se base directamente en ese documento.



4.- En caso de adaptar las WCAG 2.0 y convertirlas en norma, ¿cuál debe ser
el tratamiento de los derechos de autor?  Deberá indicarse que la norma se
basa en las WCAG 2.0, y ofrecer el enlace a: [
<http://www.w3.org/TR/WCAG20/> www.w3.org/TR/WCAG20/] Ese es el enlace a esa
versión en concreto. No debe indicarse el enlace a
[http://www.w3.org/TR/WCAG/] porque ese esa es la url de la especificación
técnica que va actualizándose. Y el copy del W3C tal como se indica en:
http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231.
Convendrá también que indiquéis la localización directa de la traducción
oficial al español: http://www.sidar.org/traducciones/wcag20/es/



5.- Si adaptáramos las WCAG 2.0, qué forma de presentación creen que debe
predominar: La norma ha de indicar, en todo caso, el nivel de prioridad de
cada uno de sus puntos normativos. La clasificación por principios puede
mantenerse a la vez que la indicación de la prioridad. Pero creo que para el
usuario de la norma sería más útil y práctico el clasificar los puntos
normativos por elementos o tipo de información, tal como aparecen en la
Norma UNE 139:803 o como aparecen en los materiales que os dimos en el curso
sobre aplicación de las WCAG 2.0 en Colombia el año pasado.



Saludos,

Emmanuelle









De: accesoweb@yahoogroups.com [mailto:accesoweb@yahoogroups.com] En nombre
de Mario
Enviado el: miércoles, 17 de marzo de 2010 5:11
Para: accesoweb@yahoogroups.com
Asunto: [AccesoWeb] Norma Técnica Colombiana del Icontec sobre Accesibilidad
Web





Hola a todos.

En Colombia, el Icontec (Instituto Colombiano de Normas Técnicas) está
trabajando en la NTC (Norma Técnica Colombiana) en Accesibilidad Web.

Me gustaría que a través de esta lista pudiéramos encontrar luces sobre
algunas dudas que tengo:

1. ¿Hay alguna norma en el mundo que esté basada en las WCAG 2.0?

2. En el vínculo de la página de Normalización del SIDAR encuentro
información sobre la norma UNE en España, según entiendo, pionera en este
terreno. ¿Hay otras normas en español sobre accesibilidad web?

3. La Unión Europea toma las Directrices de Accesibilidad como norma de
facto. ¿Qué ventajas tiene tomar las WCAG 2.0 como norma de facto, frente a
la posibilidad de adaptarlas en una norma técnica?

4. En caso de adaptar las WCAG 2.0 y convertirlas en norma, ¿cuál debe ser
el tratamiento de los derechos de autor?

5. Si adaptáramos las WCAG 2.0, qué forma de presentación creen que debe
predominar:

a) Por principios (Perceptible, Operable, Comprensible, Robusto)
b) Por criterios de conformidad (A, AA y AAA)

Muchas gracias por los aportes.

MARIO CARVAJAL
Astrolabio, Colombia





[Se han eliminado los trozos de este mensaje que no contenían texto]

Hola, alguien podría informarme su existe algún software libre o navegador para
debiles visuales, se que existe JAWS..pero hay alguno que sea gratuito?

Saludos y por la atención a este correo, gracias.

Itzel Hdez


      
________________________________________________________________________________\
____
¡Obtén la mejor experiencia en la web!
Descarga gratis el nuevo Internet Explorer 8.
http://downloads.yahoo.com/ieak8/?l=e1

>  Hola, alguien podría informarme su existe algún software libre o
> navegador para debiles visuales, se que existe JAWS..pero hay alguno que sea
> gratuito?
>
¡Hola! En Ubuntu existe Orca, e incluso hay distribuciones basadas en
Ubuntu, especialmente creadas para invidentes.

¡Saludos!
Iris Fernández


[Se han eliminado los trozos de este mensaje que no contenían texto]

Hola Iris, si necesitas un lector de pantalla gratuito, existe un proyecto de un
lector libre de código abierto. La página para descargarlo es
http://www.nvda-project.org/Tiene una versión instalable y una portable, que
podés ejecutar desde un pen drive en cualquier computadora.Saludos
Sabrina

To: accesoweb@yahoogroups.com
From: irisfernandez@...
Date: Mon, 22 Mar 2010 14:44:22 -0300
Subject: Re: [AccesoWeb] software libre para debiles visuales para navegar en 
la web




























       >  Hola, alguien podría informarme su existe algún software libre o

> navegador para debiles visuales, se que existe JAWS..pero hay alguno que sea

> gratuito?

>

¡Hola! En Ubuntu existe Orca, e incluso hay distribuciones basadas en

Ubuntu, especialmente creadas para invidentes.



¡Saludos!

Iris Fernández



[Se han eliminado los trozos de este mensaje que no contenían texto]


















_________________________________________________________________
Ahora Messenger en tu Blackberry® 8520 con Movistar por 0 €. ¿A qué esperas?
http://serviciosmoviles.es.msn.com/messenger/blackberry.aspx

[Se han eliminado los trozos de este mensaje que no contenían texto]

Hola Itzel

En Software Libre puedes encontrar muchos, te recomendaría que usaras Orca
es excelente. En el siguiente enlace te puedes descargar un manual de como
realizar la instalación

http://mundoaccesible.org.ve/documentacion.php

También si estas interesado en Software Libre te recomendaría que te
inscribieras a la lista del Grupo Mundo Accesible (Grupo de Venezuela)
nosotros solo trabajamos accesibilidad bajo herramientas libres así que si
necesitas alguna ayuda o tienes alguna pregunta puedes hacerla por la lista.

La invitación esta abierta para todos los usuarios de esta lista.

Saludos

El 23 de marzo de 2010 13:11, Itzel Hernandez <itzelhs@...> escribió:

>
>
> Hola, alguien podría informarme su existe algún software libre o navegador
> para debiles visuales, se que existe JAWS..pero hay alguno que sea gratuito?
>
> Saludos y por la atención a este correo, gracias.
>
> Itzel Hdez
>
> __________________________________________________________
> ¡Obtén la mejor experiencia en la web!
> Descarga gratis el nuevo Internet Explorer 8.
> http://downloads.yahoo.com/ieak8/?l=e1
>
>



--
--
|
|Ing. Angélica Delgado (Mia)
|http://mia.gnu.org.ve/
|http://mundoaccesible.org.ve/
|
|La accesibilidad no es un privilegio, es un derecho!


[Se han eliminado los trozos de este mensaje que no contenían texto]

hola, aclaremos que orca es para linux, mientras que nvda, es para windows
xp vista y seven de 32 y 64 bytes.
saludos cordiales
----- Original Message -----
From: "angelica delgado" <miarossell@...>
To: <accesoweb@yahoogroups.com>
Sent: Monday, March 22, 2010 3:20 PM
Subject: Re: [AccesoWeb] software libre para debiles visuales para navegar
en la web


Hola Itzel

En Software Libre puedes encontrar muchos, te recomendaría que usaras Orca
es excelente. En el siguiente enlace te puedes descargar un manual de como
realizar la instalación

http://mundoaccesible.org.ve/documentacion.php

También si estas interesado en Software Libre te recomendaría que te
inscribieras a la lista del Grupo Mundo Accesible (Grupo de Venezuela)
nosotros solo trabajamos accesibilidad bajo herramientas libres así que si
necesitas alguna ayuda o tienes alguna pregunta puedes hacerla por la lista.

La invitación esta abierta para todos los usuarios de esta lista.

Saludos

El 23 de marzo de 2010 13:11, Itzel Hernandez <itzelhs@...> escribió:

>
>
> Hola, alguien podría informarme su existe algún software libre o navegador
> para debiles visuales, se que existe JAWS..pero hay alguno que sea
> gratuito?
>
> Saludos y por la atención a este correo, gracias.
>
> Itzel Hdez
>
> __________________________________________________________
> ¡Obtén la mejor experiencia en la web!
> Descarga gratis el nuevo Internet Explorer 8.
> http://downloads.yahoo.com/ieak8/?l=e1
>
>



--
--
|
|Ing. Angélica Delgado (Mia)
|http://mia.gnu.org.ve/
|http://mundoaccesible.org.ve/
|
|La accesibilidad no es un privilegio, es un derecho!


[Se han eliminado los trozos de este mensaje que no contenían texto]



------------------------------------

Enlaces a Yahoo! Grupos







__________ Información de NOD32, revisión 4965 (20100322) __________

Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com

Hola a todos y todas:
Quería saber como es esta plataforma del asunto, respecto a su accesibilidad
tanto para lectores de pantalla como en general.
Saludos
Martín
Los archivos en formato de imagen, no son leídos por lectores de pantalla,
utilizados por personas con discapacidad visual. Por favor si adjunta una
foto, texto en formato de imagen o cualquier otro formato no textual,
incluya texto alternativo.
Lic. M. Balbinder
martinbalbinder@...

Hoola Martín, pues yo solo te puedo contar algo de mi experiencia al
intentar administrarlo. Las opciones del menú de administración como sitios,
menús y esas cosas (ahora no recuerdo exactamente que opciones eran), Jaws
no las reconocía como enlaces y si bien de vez en cuando funcionaban
llevando el cursor de Jaws a PC y haciendo click con el botón izquierdo del
ratón, a mi por lo menos, no me sucedía siempre y me ha sido imposible poder
configurarlo.

Nunca he podido avanzar más de la página de administración, no conseguía
activar ninguna de las opciones.

Un saludo y a ver si alguien nos cuenta algo mas.



-----Mensaje original-----
De: accesoweb@yahoogroups.com [mailto:accesoweb@yahoogroups.com] En nombre
de Martin Balbinder
Enviado el: miércoles, 24 de marzo de 2010 0:49
Para: accesoweb@yahoogroups.com
Asunto: [AccesoWeb] joomla

Hola a todos y todas:
Quería saber como es esta plataforma del asunto, respecto a su accesibilidad
tanto para lectores de pantalla como en general.
Saludos
Martín
Los archivos en formato de imagen, no son leídos por lectores de pantalla,
utilizados por personas con discapacidad visual. Por favor si adjunta una
foto, texto en formato de imagen o cualquier otro formato no textual,
incluya texto alternativo.
Lic. M. Balbinder
martinbalbinder@...



------------------------------------

Enlaces a Yahoo! Grupos

Buenos días.

Hace tiempo encontré este enlace:

http://accesibilidadenlaweb.blogspot.com/2009/04/accesibilidad-de-joomla.html

Como todos, para cuando tuviese tiempo :(. Espero que te pueda servir.

2010/3/24 Jose María Ortiz Silva <jortiz015@...>

>
>
> Hoola Martín, pues yo solo te puedo contar algo de mi experiencia al
> intentar administrarlo. Las opciones del menú de administración como
> sitios,
> menús y esas cosas (ahora no recuerdo exactamente que opciones eran), Jaws
> no las reconocía como enlaces y si bien de vez en cuando funcionaban
> llevando el cursor de Jaws a PC y haciendo click con el botón izquierdo del
> ratón, a mi por lo menos, no me sucedía siempre y me ha sido imposible
> poder
> configurarlo.
>
> Nunca he podido avanzar más de la página de administración, no conseguía
> activar ninguna de las opciones.
>
> Un saludo y a ver si alguien nos cuenta algo mas.
>
> -----Mensaje original-----
> De: accesoweb@yahoogroups.com <accesoweb%40yahoogroups.com> [mailto:
> accesoweb@yahoogroups.com <accesoweb%40yahoogroups.com>] En nombre
> de Martin Balbinder
> Enviado el: miércoles, 24 de marzo de 2010 0:49
> Para: accesoweb@yahoogroups.com <accesoweb%40yahoogroups.com>
> Asunto: [AccesoWeb] joomla
>
>
> Hola a todos y todas:
> Quería saber como es esta plataforma del asunto, respecto a su
> accesibilidad
> tanto para lectores de pantalla como en general.
> Saludos
> Martín
> Los archivos en formato de imagen, no son leídos por lectores de pantalla,
> utilizados por personas con discapacidad visual. Por favor si adjunta una
> foto, texto en formato de imagen o cualquier otro formato no textual,
> incluya texto alternativo.
> Lic. M. Balbinder
> martinbalbinder@... <martinbalbinder%40gmail.com>
>
> ------------------------------------
>
> Enlaces a Yahoo! Grupos
>
>
>


[Se han eliminado los trozos de este mensaje que no contenían texto]

Apologies for cross-postings. Please send to interested colleagues and students

-- CALL FOR PAPERS - Deadline for submissions (new date): 29 March 2010 --

IADIS INTERNATIONAL CONFERENCE INTERFACES AND HUMAN COMPUTER INTERACTION 2010
Freiburg, Germany, 28 – 30 July 2010
(http://www.ihci-conf.org/)
part of the IADIS Multi Conference on Computer Science and Information Systems
(MCCSIS 2010)
Freiburg, Germany, 26 – 31 July 2010
(http://www.mccsis.org)

* Conference background and goals
The IADIS Interfaces and Human Computer Interaction (IHCI) 2010 conference aims
to address the main issues of concern within Interface Culture and Design with a
particular emphasis on the affective aspects of design,
development and implementation of interfaces and the generational implications
for design of human and technology interaction. This conference aims to explore
and discuss innovative studies of technology and its application in interfaces
and welcomes research in progress, case studies, practical demonstrations and
workshops in addition to the traditional submission categories.

* Format of the Conference
The conference will comprise of invited talks and oral presentations. The
proceedings of the conference will be published in the form of a book and CD-ROM
with ISBN, and will be available also in the IADIS Digital Library (accessible
on-line).

* Best Papers
Selected authors of best papers will be invited to submit extended versions of
their papers to selected journals (i.e. IADIS International Journal on Computer
Science and Information Systems - ISSN: 1646-3692) including journals from
INDERSCIENCE Publishers.

* Types of submissions
Full and Short Papers, Reflection Papers, Posters/Demonstrations, Tutorials,
Panels and Doctoral Consortium.
All submissions are subject to a blind refereeing process.

* Topics related to Interfaces and Human Computer Interaction are of interest.
These include, but are not limited to the following areas:

- Affective User-centred analysis, design and evaluation
- The value of Affective Interfaces/ Systems/Application/ Interaction
- Generational differences and technology design
- Measurement of success of emotional technology/interfaces
- Supporting user populations from difference generations
- Supporting user populations with Physical Disabilities
- Supporting user populations with Intellectual Disabilities
- Creativity Support Systems
- Emotional Design issues/methods/experiences for novel interfaces including
tangible, mixed reality
   interfaces and multi-modal interfaces
- Emotional Design issues/methods/experiences for mobile and ubiquitous
computing
- Usability
- User studies and fieldwork
- Methodological implications of emotional user studies.
- Participatory design and cooperative design techniques
- Ethical issues in emotional design
- HCI education and design education
- Eliciting User Requirements

* Important Dates:
- Submission Deadline (new date): 29 March 2010
- Notification to Authors (new date): 30 April 2010
- Final Camera-Ready Submission and Early Registration (new date): Until 24 May
2010
- Late Registration (new date): After 24 May 2010
- Conference: Freiburg, Germany, 28 – 30 July 2010

* Conference Location
The conference will be held in Freiburg, Germany.

* Secretariat
IADIS Secretariat - IADIS INTERNATIONAL CONFERENCE INTERFACES AND HUMAN COMPUTER
INTERACTION 2010
Rua Sao Sebastiao da Pedreira, 100, 3
1050-209 Lisbon, Portugal
E-mail: secretariat@...
Web site: http://www.ihci-conf.org/

* Program Committee

Interfaces and Human Computer Interaction 2010 Conference Program Chair
Katherine Blashki, University of Sydney, Australia

General MCCSIS 2010 Conference Co-Chairs:
Piet Kommers, University of Twente, The Netherlands
Pedro Isaías, Universidade Aberta (Portuguese Open University), Portugal
Dirk Ifenthaler, Albert-Ludwigs-Universität Freiburg, Germany
Nian-Shing Chen, National Sun Yat-sen University, Taiwan

Committee Members: *
* for committee list please refer to http://www.ihci-conf.org/committees.asp

Hola a todos nuevamente:
Alguien podría darme información sobre el asunto del mensaje?
Agradezco también las respuestas que me han dado sobre Jomla y por las que
puedan darme sobre este tema.
Saludos
Martín
Los archivos en formato de imagen, no son leídos por lectores de pantalla,
utilizados por personas con discapacidad visual. Por favor si adjunta una
foto, texto en formato de imagen o cualquier otro formato no textual,
incluya texto alternativo.
Lic. M. Balbinder
martinbalbinder@...

> Alguien podría darme información sobre el asunto del mensaje?

¿Qué tipo de información sobre WordPress?
Es un CMS libre.

Saludos,
Iris Fernández

Hola Iris, gracias por responder.
Me refería a su accesibilidad, tanto para lectores de pantalla como en
general.
Saludos
Martín
Los archivos en formato de imagen, no son leídos por lectores de pantalla,
utilizados por personas con discapacidad visual. Por favor si adjunta una
foto, texto en formato de imagen o cualquier otro formato no textual,
incluya texto alternativo.
Lic. M. Balbinder
martinbalbinder@...
   ----- Mensaje original -----
   De: Iris Fernández
   Para: accesoweb@yahoogroups.com
   Enviado: Viernes, 26 de Marzo de 2010 08:23 a.m.
   Asunto: Re: [AccesoWeb] wordpress



   > Alguien podría darme información sobre el asunto del mensaje?

   ¿Qué tipo de información sobre WordPress?
   Es un CMS libre.

   Saludos,
   Iris Fernández





----------------------------------------------------------------------------

     avast! Antivirus: Mensaje entrante limpio.

     Base de datos de Virus (VPS): 100325-1, 25/03/2010
     Comprobado el: 26/03/2010 01:13:17 p.m.
     avast! - copyright (c) 1988-2010 ALWIL Software.



[Se han eliminado los trozos de este mensaje que no contenían texto]

>
> Me refería a su accesibilidad, tanto para lectores de pantalla como en
> general.
>
Mi experiencia es que con WordPress se puede hacer un sitio que valide, y
después hay que cuidar permanentemente la accesibilidad de los nuevos
contenidos. Humildemente en mi blog [1], que hace algunos años hago en
WordPress, creo que logré bastante, aunque su contenido es permanentemente
renovado y a veces no valide por un tiempito (hasta que me doy cuenta, o me
avisan).

Saludos!!
Iris Fernández
[1] www.irisfernandez.com.ar/betaweblog


[Se han eliminado los trozos de este mensaje que no contenían texto]

Queridos amigos y amigas:
Ignoro si esta herramienta había sido citada antes, pero por las
dudas, paso la información.
En la siguiente dirección se encuentra una herramienta que nos permite
revisar cómo se vería una página web en línea con distintas
resoluciones de pantalla:

http://www.viewlike.us/

Las resoluciones disponibles son de iPhone, del navegador de Wii, 800
por 600, 1024 por 768, 1152 por 864, 1280 por 800, 1400 por 900, 1600
por 1200 y 1920 por 1200. Falta, de las que recuerdo, la vieja y
querida definición de 640 por 480 y de otros dispositivos móviles.
Un fuerte abrazo a todos.

Claudio

--
Claudio Segovia
claudiosegovia@...
Lago Puelo - Chubut - Argentina
La información en formato de imagen, no pueden ser leída por los
lectores de pantalla, utilizados por personas con problemas visuales.
Por favor incluya texto alternativo.
http://www.alberguedenaufragos.com.ar
http://www.lenguaseinternet.com.ar
http://www.alberguedenaufragos.com.ar/textos/accesibilidad.pdf

He tenido muchos problemas con dominios de mi organizacion que son publicos.
Probe con algunos diarios y funciono bien.

  Muy util, gracias.

Gabriel Bulfon | gbulfon@... |
Skype: callto://gbulfon |blog:
http://www.dotech.com.ar/blogs/gbulfon/index.htm


2010/3/26 Claudio Segovia <claudiosegovia@...>

>
>
> Queridos amigos y amigas:
> Ignoro si esta herramienta había sido citada antes, pero por las
> dudas, paso la información.
> En la siguiente dirección se encuentra una herramienta que nos permite
> revisar cómo se vería una página web en línea con distintas
> resoluciones de pantalla:
>
> http://www.viewlike.us/
>
> Las resoluciones disponibles son de iPhone, del navegador de Wii, 800
> por 600, 1024 por 768, 1152 por 864, 1280 por 800, 1400 por 900, 1600
> por 1200 y 1920 por 1200. Falta, de las que recuerdo, la vieja y
> querida definición de 640 por 480 y de otros dispositivos móviles.
> Un fuerte abrazo a todos.
>
> Claudio
>
> --
> Claudio Segovia
> claudiosegovia@... <claudiosegovia%40sidar.org>
> Lago Puelo - Chubut - Argentina
> La información en formato de imagen, no pueden ser leída por los
> lectores de pantalla, utilizados por personas con problemas visuales.
> Por favor incluya texto alternativo.
> http://www.alberguedenaufragos.com.ar
> http://www.lenguaseinternet.com.ar
> http://www.alberguedenaufragos.com.ar/textos/accesibilidad.pdf
>
>


[Se han eliminado los trozos de este mensaje que no contenían texto]

El 26 de marzo de 2010 20:57, Claudio Segovia
<claudiosegovia@...>escribió:

>
> En la siguiente dirección se encuentra una herramienta que nos permite
> revisar cómo se vería una página web en línea con distintas
> resoluciones de pantalla:
>

Yo conocía este, supongo que lo habrán mencionado en esta lista, pero ante
la duda lo recuerdo:

http://browsershots.org/

¡Saludos!
Iris Fernández


[Se han eliminado los trozos de este mensaje que no contenían texto]

¡Gracias Iris!
No, por lo menos yo no la conocía, aunque mi memoria no es garantía de nada
[sonrisa].
Es mucho más completo, aunque para mi gusto, el de ViewLikeUs es más
sencillo de comprender su uso.
Un detalle que no es menor (y a favor de tu aporte): ViewLikeUs sólo está en
inglés, por lo que puede resultar confuso para algunos usuarios, mientras
que Browsershots permite elegir entre varias lenguas, además de tomar la
lengua del navegador como primera opción.

Claudio

El 26 de marzo de 2010 23:00, Iris Fernández <irisfernandez@...>escribió:

>
>
> El 26 de marzo de 2010 20:57, Claudio Segovia
> <claudiosegovia@... <claudiosegovia%40sidar.org>>escribió:
>
>
> >
> > En la siguiente dirección se encuentra una herramienta que nos permite
> > revisar cómo se vería una página web en línea con distintas
> > resoluciones de pantalla:
> >
>
> Yo conocía este, supongo que lo habrán mencionado en esta lista, pero ante
> la duda lo recuerdo:
>
> http://browsershots.org/
>
> ¡Saludos!
> Iris Fernández
>
>
> [Se han eliminado los trozos de este mensaje que no contenían texto]
>
>
>



--
Claudio Segovia
claudiosegovia@...
Lago Puelo - Chubut - Argentina
La información en formato de imagen, no pueden ser leída por los lectores de
pantalla, utilizados por personas con problemas visuales. Por favor incluya
texto alternativo.
http://www.alberguedenaufragos.com.ar
http://www.lenguaseinternet.com.ar
http://www.alberguedenaufragos.com.ar/textos/accesibilidad.pdf


[Se han eliminado los trozos de este mensaje que no contenían texto]

hola  Martin
el wordpress que yo conozco es un sitio que lleva ese nombre y te permite editar
un blog con esa extension, es un poquito mas sofisticado que blogger.
mi blog esta editado en ese sitio y es
http://disfonema.wordpress.com/
si te referis a otro, avisa
saludos

Clarisa

--- En accesoweb@yahoogroups.com, Iris Fernández <irisfernandez@...> escribió:
>
> > Alguien podría darme información sobre el asunto del mensaje?
>
> ¿Qué tipo de información sobre WordPress?
> Es un CMS libre.
>
> Saludos,
> Iris Fernández
>

Hola a todos,



El proyecto europeo “Accessible” ha lanzado una llamada a diseñadores,
desarrolladores y usuarios con discapacidad para participar en la revisión
de los productos que genere el proyecto.



Me temo que es necesario saber inglés. La llamada la encontraréis en:

  <http://www.accessible-project.eu/index.php/open-call-for-experts.html>
http://www.accessible-project.eu/index.php/open-call-for-experts.html



Saludos,

Emmanuelle







  <http://www.sidar.org/>

  <http://www.sidar.org/> Por una web accesible e inclusiva para TODOS




Emmanuelle Gutiérrez y Restrepo
Directora

Fundación Sidar


  <mailto:emmanuelle@...> emmanuelle@...
  <http://www.sidar.org/> http://www.sidar.org/


tel:
móvil:

+34-917257147
+34-655986996







[Se han eliminado los trozos de este mensaje que no contenían texto]