sábado, 18 de abril de 2015

Carlos Neri, amigo y colaborador incansable

Carlos Neri ha dejado un importante vacío en el Seminario SIDAR que será imposible de llenar. Llegó a mi vida personal y a la del Seminario SIDAR de la mano de Graciela Caplan, a quién lamentablemnte también hemos de echar mucho de menos. Juntos conformaban un equipo sin igual y, sin ellos, seguramente no se habría extendido tanto la actividad del SIDAR en Argentina.

Carlos Neri, en las X Jornadas Sidar
Foto de Mario Carvajal

Carlos participó muy activamente desde su ingreso en 2001, ocupándose de coordinar conjuntamente con Graciela, desde el 17 de enero de 2005, el Grupo de Interés en Contenidos (G2), que se centraba en el seguimiento y promoción de sinergias de los contenidos Web y, a partir del 2005, ahondando en las necesidades de la formación en accesibilidad, precisamente por iniciativa suya.

En 2007 se celebró el décimo aniversario del SIDAR. Hubo múltiples celebraciones en varios países y, naturalmente hubo una celebración especial en Argentina . Para esa celebración escribí un discurso en el que destacaba algunos nombres, en representación de todos los argentinos que conforman el SIDAR y, como no podía ser de otra forma, entre ellos el de Carlos. Comparto aquí lo que en aquél momento dije:
"Carlos Neri: De la mano de Graciela vino Carlos Neri, si no recuerdo mal. Carlos ha asumido una tarea difícil y poco satisfactoria: Coordinar el grupo de interés sobre contenidos (G2). Es una tarea poco satisfactoria porque no parece tan atractiva para los diseñadores, más volcados en las cuestiones de lenguajes de marcado y de efectos visuales. Pero si ahondamos en la cuestión, los contenidos son la esencia de la web. Y aunque quizás en estos primeros tiempos de evolución del tema que nos ocupa, no se vea un entusiasmo generalizado por participar en ese grupo de interés, el nivel académico de las aportaciones de Carlos es indiscutible y en un futuro próximo serán valoradas en su justa medida. Gracias, Carlos, por seguir ahí, a pesar de todo; por estar atento, cuidar discretamente de la imagen del Seminario y elevar su nivel."
Y es que, quizás precisamente ese nivel académico haya sido demasiado alto para los participantes más interesados en la solución rápida a sus problemas cotidianos de creación de páginas web, poco interesados estos en la reflexión, la investigación y las sinergias científicas y académicas; en las que otros sí que estamos muy interesados y, por tanto, hemos valorado tanto en las aportaciones de Carlos.

Muestra de ello son sus libros y, por supuesto, sus ponencias en las distintas Jornadas del SIDAR y que pueden descargarse desde la sede web de la Fundación Sidar – Acceso Universal:
La vida no nos dio muchas más oportunidades de encontrarnos personalmente, pero al menos la llamada web 2.0 nos mantenía en permanente contacto. En ella compartíamos reflexiones, risas y en ocasiones tristezas. Además él compartía algunos actos de su vida privada en familia. Creo que como marido y padre, siempre fue ejemplar. Con su mujer, Diana Fernández Salazar, trabajó intensamente en colaboración en la Cátedra de Psicología. En lo personal, nunca olvidaré las fotos que se hacía cada año, con ocasión del cumpleaños de Malena, su hija, siempre en el mismo sitio y en la misma pose, con ella sobre sus hombros. Malena crecía y cada vez se veía más imposible la pose. Queda un tierno recuerdo y espero que también para ella, sirva este sentido homenaje a lo que fue su participación en el Seminario SIDAR.

Carlos, siempre sonriente, era una persona expansiva, inteligente y prueba de su generosidad es el trabajo que dedicó a la accesibilidad y a alentar a todos a ver la web con otros ojos. Carlos no nos ha dejado, porque su recuerdo pervivirá en todos los que le conocimos y en sus obras, que estoy segura inspirarán a muchos en el futuro.

¡Gracias por todo, Carlos!

sábado, 28 de marzo de 2015

Marcado HTML y semántico, sensibles.

Muchos sitios cuentan con la publicidad para mantenerse, pero hay casos en los que los anuncios publicitarios pueden resultar groseros, e incluso generar una experiencia de usuario negativa y contraria a la deseada por los autores del sitio. Es el caso de la publicación de una noticia o entrada de blog referida a una tragedia o a un hecho especialmente sensible, como ha sido el del vuelo 4U9525.

Algunos de los mas importantes sitios de noticias de Estados Unidos demostrando su sensibilidad y previniendo que se den casos ofensivos por pura casualidad en la relación que se crea entre un titular, una foto, o el contenido de una noticia y la publicidad que aparece a su lado, están utilizando marcado HTML y/o marcado semántico para evitar la publicación de publicidad junto a noticias referidas a tragedias. Es lo que podríamos llamar, marcado responsable.

Según ha descubierto Parker Higguins de la Electronic Frontier Foundation, el New York Times utiliza el elemento meta para ello:

<meta property="ad_sensitivity" content="noads" />

captura de pantalla que muestra el elemento en el diario.
captura de pantalla del código fuente de una noticia en el New York Times

De esta manera se indica que al contenido de la página no se le añadan elementos publicitarios. Se trata de una opción que tiene su gestor de contenidos (CMS, por sus siglas en inglés) y que facilita que los autores puedan indicar que se trata de "contenido sensible" y eso genera la etiqueta meta citada. Al parecer ofrece 3 niveles: standard, noads y tragedy.

Por su parte, la versión digital de CNN no añade publicidad a los vídeos cuando se trata de casos trágicos, según ha indicado la portavoz de la cadena. Y las cabeceras de noticias quedan marcadas en su código HTML con la clase: "screaming banner", como puede verse en la siguienta captura de pantalla tomada del blog Slate, mediante el que he conocido este caso.
Captura de pantalla de la web de CNN destacando el código fuente de la cabecera.
Código fuente de la web de la CNN.
No parece ser el caso de los medios de comunicación españoles. Al menos no he encontrado nada similar en los que he visitado. En cambio sí que he encontrado un buen ejemplo negativo. No diré de qué web se trata, por aquello de que "se cuenta el milagro pero no el santo", pero es claro que no resulta muy apropiado, puede llevar a un chiste de mal gusto, el que el titular sea: "Lubitz llevaba semanas discutiendo con su novia y en proceso de ruptura" y que junto a la noticia aparezca un banner publicitario que dice: "Tengo el día tonto", como puede apreciarse en las siguientes capturas de pantalla:
Noticia sobre el estado emocional del copiloto.
Noticia en un diario español

Contenido de la noticia con un banner publicitario que resulta poco apropiado.
Banner publicitario al lado de la noticia y que por yuxtaposición resulta inapropiado.
La atención sensible al contenido, eliminando la publicidad en ciertos casos, es algo que viene haciendo desde hace tiempo Google en su servicio de correo. Cuando el mensaje contiene ciertas palabras en una cantidad de contenido dado, una por cada 167, se elimina la publicidad. Palabras como sucidio, asesinato, 9/11, etc.

Lamentablemente, en nuestro mundo, hoy en día, son constantes los casos en los que recibimos o tenemos que dar noticias trágicas y el hecho de ocuparse en utilizar el marcado semántico para eliminar la publicidad y no lucrarse de ellas es, cuando menos, aplaudible y un buen ejemplo de sensibilidad y marcado responsable.

viernes, 27 de marzo de 2015

Novedades de accesibilidad en Acrobat DC y Reader DC

Matt May publica en el Blog de Adobe que, la empresa ha anunciado esta semana que en los próximos 30 días lanzarán una nueva versión de Acrobat DC y Reader DC con mejoras de accesibilidad.
Las novedades son pocas pero importantes:
  • Adobe Acrobat y Adobe Reader permitirán la lectura de contenido etiquetado en PDF mediante tecnologías de apoyo (ayudas técnicas) tanto sobre Windows como sobre Mac OS X. Lo que implica que por primera vez los usuarios de VoiceOver podrán crear, editar y leer documentos PDF accesibles.
  • También se ha mejorado la interfaz de Acrobat y de Reader, incluyendo características que permitirán utilizar tanto el editor como el lector en modos de alto contraste, con nuevos iconos tanto para fondos claros como para fondos oscuros.
  • Las opciones de accesibilidad para la autoría en Acrobat se encuentran ahora organizadas en la "Accessibility Tool" (Herramientas de Accesibilidad) que, además, es más configurable que en versiones anteriores. Mientras que en la "Actions Tool" sigue apareciendo la "Make Accessible Action" junto con una serie de componentes que pueden usarse para revisar y automatizar la producción de documentos PDF accesibles.
  • Estan trabajando en la creación de nueva documentación sobre accesibilidad tanto para autores como para usuarios

Captura de pantalla de la interfaz en alto contraste.
Interfaz en alto contraste de la nueva versión de Acrobat que se publicará en breve.

sábado, 21 de marzo de 2015

Comparativa de buenas prácticas para el diseño web móvil (MWBP) y pautas de accesibilidad web (WCAG)


Que tu web sea "amigable" para con los dispositivos móviles es hoy en día una necesidad, no sólo porque cada vez más usuarios utilizan esos dispositivos para acceder a contenidos en la web (véase el informe Sociedad de la Información en España 2014, por ejemplo) sino que es ya una exigencia por parte de algunas compañías de motores de búsqueda e indización (es el caso, por ejemplo de Google). Para conseguirlo debemos seguir las buenas prácticas para el diseño web móvil y, quienes llevamos tiempo trabajando por y para la accesibilidad llevamos ventaja en ello. Según mis análisis por el mero hecho de tener experiencia en accesibilidad cubres ya el 70% de los requisitos para que tu web sea amigable con los dispositivos móviles.

La cuestión de la mejora de la indización y posicionamiento en estos días es ya crítica dado que, por ejemplo, Google ha decidido penalizar las web que no sean amigables con los dispositivos móviles y está enviado a los webmaster mensajes como el siguiente:

Captura de pantalla de un mensaje de parte de google advirtiendo al webmaster que su web contiene errores de usabilidad en móviles y le sugiere algunas herramientas y tutoriales que le ayudarán a corregirlos.
Captura de pantalla del mensaje enviado por Google a los webmasters



En el blog de Google "Web Masters Central Blog" se publicó la noticia indicando que, a partir del 21 de abril considerarán la amigabilidad para con dispositivos móviles en su cálculo para determinar el ranking en el que se posicionarán las páginas. Por tanto, si tu web no cumple con las buenas prácticas para el diseño web móvil no se presentará en los primeros lugares cuando un usuario haga una búsqueda de las palabras clave relacionadas con tu sitio.

Google ofrece a los webmasters una serie de tutoriales y herramientas para facilitarle aplicar esos criterios que facilitarán que su web se presente adecuadamente cuando el usuario utiliza un dispositivo móvil. Pero, ¿son esos criterios muy diferentes de los que venimos aplicando desde la perspectiva de la accesibilidad?. La respuesta es no, en absoluto. Es más, como decía, el 70% de ellos quedan cubiertos por la experiencia de aquellos que vengan aplicando las pautas de accesibilidad desde hace años.

En la siguiente tabla se presenta el análisis que he hecho sobre la equivalencia entre las buenas prácticas para la web móvil (MWBP, por sus siglas en inglés) y las pautas de accesibilidad para el contenido en la web (WCAG, por sus siglas en inglés).

Para el estudio he utilizado los siguientes documentos:


La tabla recoge las 60 pautas de buenas prácticas para la web móvil, pero lo hace presentando en primer lugar las 7 pautas que quedan totalmente cubiertas por las WCAG 2.0, en segundo lugar aquellas para las que posiblemente no habría que hacer nada o que quedan parcialmente cubiertas y que son 16 y, finalmente, las 40 que teóricamente no quedan cubiertas. Si las cuentas no salen es porque hay dos pautas repetidas (alternativas para contenido no textual e identificación de los enlaces) debido a que se presentan tanto en la columna que indica que quedan cubiertas como en la columna que indica que pueden estar parcialmente cubiertas por otros criterios de las WCAG 2.0, según el documento comparativo con las WCAG 2.0 anteriormente mencionado.

En cuanto a las WCAG 1.0, aparecen en la última columna y cubrirían total o parcialmente 37 de las pautas para la web móvil, lo que supone el 61%. Solamente 18 pautas para la web móvil no quedan cubiertas por ningún criterio, ni de la versión 1.0 ni de la versión 2.0; es decir, tan sólo un 30%.

Es de destacar que, comparando los documentos "From WCAG 2.0 to MWBP" y "From WCAG 1.0 to MWBP" resultan 13 los criterios de buenas prácticas para el diseño web móvil que quedan cubiertos sólo por las WCAG 1.0, un 22%, pero no por las WCAG 2.0. Es decir, aquellos que se han acercado al mundo de la accesibilidad después de 2008, han tenido que aprender a integrar en sus hábitos de diseño y desarrollo ciertas prácticas sólo a la luz de la compatibilidad con móviles, pero en cambio quienes llegaron antes ya tenían esos buenos hábitos.

He agregado, indicando mis iniciales (EGYRS) aquellos criterios que creo cubren totalmente o en parte lo requerido para la web móvil y que no se indican en los documentos comparativos anteriormente citados. Como resultado, serían 17 las pautas que quedan totalmente cubiertas por las WCAG, 15 las que posiblemente se cubrirían y 10 las que quedarían parcialmente cubiertas: lo que hace un total de 42 y supone el 70%.

En mi análisis he añadido los equivalentes para los criterios de las WCAG 1.0 existentes en la WCAG 2.0, aunque en algunos casos debidos a técnicas recomendables y no requeridas, por lo que algunos desarrolladores las desconocen, pero son habituales en aquellos con mayor experiencia en la accesibilidad. Así que, la diferencia no es tan grande y, precisamente en dichos añadidos es donde puede estribar el interés de mi análisis, porque según éste sólamente dos criterios de las WCAG 1.0 no tienen equivalente en las WCAG 2.0 que puedan cubrir lo solicitado por las buenas prácticas para la web móvil.

Resumiendo, quien conozca y venga aplicando las pautas de accesibilidad para el contenido web de antiguo, estará cumpliendo ya con el 70% de los criterios de buenas prácticas para la web móvil.


Equivalencia entre criterios de MWBP y WCAG.
Criterio MWBP Cubierta 2.0 Posible/ 2.0 Parcial/ 2.0 Cubierta 1.0
AUTO_REFRESH
No cree páginas que se autorrefrescan periódicamente, a menos que haya informado al usuario y proporcionado un modo de detener el refresco.
3.2.5 AAA - - 7.4 P2, 7.5 P2 y 10.1 P2
FONTS
No dependa del soporte a estilos para fuentes.
1.3.1 A - - 6.1 P1 y 11.2 P2
LINK_TARGET_ID
Identifique claramente el propósito de cada enlace.
2.4.9 AAA - - 13.1 P2
NON-TEXT_ALTERNATIVES
Proporcione un texto equivalente para cada elemento no textual.
1.1.1 A - - 1.1 P1, 3.1 P2, 6.2 P1,
STYLE_SHEETS_USE
Use hojas de estilo para controlar la presentación y disposición, a menos que sepa que el dispositivo no las soporta.
1.3.1 A - - 3.3 P2
TAB_ORDER
Cree un orden lógico de tabulación a través de enlaces, controles de formulario y objetos.
2.4.3 A - - 9.4 P3
USE_OF_COLOR
Asegúrese de que la información transmitida mediante el color está también disponivle sin color.
1.4.1 A - - 2.1 P1
BACKGROUND_IMAGE_READABILITY
Si usa imágenes de fondo asegúrese de que el contenido sigue siendo legible en el dispositivo.
- 1.4.3 AA y 1.4.6 AAA - 2.2 P2
COLOR_CONTRAST
Asegúrese de que las combinaciones de color de fondo y frente proporcionan suficiente contraste.
- - 1.4.3 AA y 1.4.6 AAA 2.1 P1 y 2.2 P2 para imágenes y P3 para textos.
CONTROL_LABELLING
Etiquete todos los controles de formulario adecuadamente y asocie las etiquetas explícitamente con sus controles.
- 1.3.1, 3.3.2, 4.1.2 A - 10.2 P2 y 12.4 P2
CONTROL_POSITION
Coloque las etiquetas de manera que adecuada en relación al control al que se refiere.
- 1.3.1 A - 10.2 P2 y 12.4 P2
GRAPHICS_FOR_SPACING
No utilice gráficos para crear espacios.
- 1.3.1 A - 3.1 P2
LINK_TARGET_ID
Identifique claramente el propósito de cada enlace.
- - 2.4.4 A 13.1 P2
MEASURES
No use medidas en px y no utilice medidas absolutas en los valores de los atributos del lenguaje de marcado y en los valores de ls propiedades de las hojas de estilo.
- 1.4.4 A - 3.4 P2
NAVIGATION
Proporcione mecanismos de navegación consistentes.
- - 3.2.3 AA y 2.4.10 AAA. EGYRS: 3.2.4 AA 13.4 P2
NON-TEXT_ALTERNATIVES
Proporcione un texto equivalente para cada elemento no textual.
1.1.1 A - EGYRS: 1.2.8 AAA y 1.2.9 AAA (En el documento de comparativa apunta a 1.2.7, pero eso es un error) 1.1 P1
PAGE_TITLE
Proporcione un título corto pero descriptivo para la página.
- 2.4.2 A - 13.2 P2
POP_UPS
No genere pop-ups o que se abran otras ventanas y no cambie la ventana actual sin advertirlo al usuario.
- 3.2.5 AAA 3.2.1 y 3.2.2 A 10.1 P2
REDIRECTION
No utilice el marcado para redirigir páginas automáticamente. En vez de ello, configure el servidor para llevar a cabo las redirecciones mediante códigos HTTP 3xx.
- 2.2.1 A, 2.2.4 y 3.2.5 AAA - 7.5 P2
STRUCTURE
Use las características del lenguaje de marcado para indicar la estructura lógica del documento.
- 1.3.1 A, 2.4.6 AA y 2.4.10 AAA - 3.5 P2
STYLE_SHEETS_SUPPORT
Organice los documentos de manera que si es necesario puedan ser leídos sin hojas de estilo.
- 1.3.1 A - 6.1 P1
VALID_MARKUP
Cree documentos válidos de acuerdo con las gramáticas formales.
- 4.1.1 A - 3.2 P2, 11.1 P2, y 11.2 P2
ACCESS_KEYS
Asigne atajos de teclado a los enalces de los menú de navegación y a las funcionalidades frecuentemente utilizadas.
EGYRS: 2.4.1 A (Técnica aconsejable) - - 9.5 P3
AVOID_FREE_TEXT
En lo posible, evite la entrada de texto libre.
- - - -
[BALANCE]
Tenga en cuenta el equilibrio entre tener demasiados enlaces en una página y pedir al usuario que siga demasiados enlaces para llegar a lo que están buscando.
- EGYRS: 2.4.5 AA - -
CACHING
Proporcione información de caché en las respuestas HTTP.
- - - -
CAPABILITIES
Aproveche las capacidades del dispositivo para proporcionar una experiencia de usuario mejorada.
- - - -
CENTRAL_MEANING
Asegúrese de que el material que es importante para el significado de la página precede al que no lo es.
EGYRS: 2.4.5 AA (G125 y G126) - - 13.5 P3
CHARACTER_ENCODING_SUPPORT
Asegúrese de que el contenido está codificado utilizando una codificación de caracteres que sabe que es soportada por el dispositivo.
- - - -
CHARACTER_ENCODING_USE
Indique en la respuesta la codificación de caracteres que se está usando.
- - - -
CLARITY
Use lenguaje claro y simple.
EGYRS: 3.1.5 AAA - - 13.8 P3 y 14.1 P1
CONTENT_FORMAT_PREFERRED
Cuando sea posible, envíe contenido en el formato preferido por el dispositivo.
- - - EGYRS: 11.3 P3
CONTENT_FORMAT_SUPPORT
Envíe contenido en un formato que se sepa será soportado por el dispositivo.
- - - EGYRS: 11.3 P3
COOKIES
No dependa de que las cookies estarán disponibles.
- - - -
DEFAULT_INPUT_MODE
Especifique un modo de entrada de texto por defecto, idioma y/o formato de entrada, si sabe que el dispositivo lo soporta.
- - - -
DEFICIENCIES
Siga pasos razonables para cubrir las deficiencias de implementación con soluciones temporales.
EGYRS: No por las WCAG pero es habitual tener que cubrir las deficiencias de los agentes de usuarios. - - -
ERROR_MESSAGES
Proporcione mensajes de error informativos y medios para salir de un mensaje de error de vuelta a la información útil.
- EGYRS: 2.1.2 A, 3.3.4 AA y 3.3.6 AAA - -
EXTERNAL_RESOURCES
Mantenga al mínimo el número de recursos externos enlazados.
- - - -
IMAGE_MAPS
No utilice mapas de imágen a menos que sepa con seguridad que el dispositivo lo soporta eficazmente.
EGYRS: 1.1.1 A, 2.1.1 A y 2.4.4 A - - 1.2 P1 y 9.1 P1
IMAGES_RESIZING
Maneje el tamaño de las imágenes desde el servidor, si tienen un tamaño intrínseco.
EGYRS: G146 para 1.4.8 AAA - - -
IMAGES_SPECIFY_SIZE
Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
- - - -
LARGE_GRAPHICS
No utilice imágenes que no podrán ser renderizadas por el dispositivo. Evite imágenes grandes o de alta resolución excepto cuando en otro caso se perdería información crítica.
- - - -
LIMITED
Limite el contenido a lo que el usuario ha solicitado.
EGYRS: 2.4.6 AA y 3.1.5 AAA - - 13.8 P3 y 14.1 P1
LINK_TARGET_FORMAT
Advirta sobre el formato de los ficheros enlazados a menos que sepa que el dispositivo lo soporta.
EGYRS: 2.4.4 A, y 2.4.9 AAA - - 11.3 P3 y 13.1 P2
MINIMIZE
Utilice el marcado de manera escueta y eficiente.
- - - -
MINIMIZE_KEYSTROKES
Mantenga al mínimo el número de pulsaciones de teclas.
- - - -
NAVBAR
Proporcione una barra de navegación mínima al inicio de la página.
- EGYRS: 2.4.5 AA - 13.5 P3
NO_FRAMES
No use marcos.
- - - -
OBJECTS_OR_SCRIPT
No dependa de objetos embebidos o scripts.
- - EGYRS: 1.1.1 A 6.3 P1, 6.5 P2 y 9.2 P2.
PAGE_SIZE_LIMIT
Asegúrese de que el peso total de la página es apropiado para las limitaciones de memoria del dispositivo.
- - - -
PAGE_SIZE_USABLE
Divida las páginas en porciones de tamaño limitado pero que resulten usables.
- - EGYRS: 2.4.10 AAA 12.3 P2
PROVIDE_DEFAULTS
Proporcione valores por defecto preseleccionados cuando sea posible.
- - - 10.4 P3
SCROLLING
Limite el desplazamiento a una dirección, a menos que no pueda evitarse un desplazamiento secundario.
- - EGYRS: 1.4.8 AAA -
STYLE_SHEETS_SIZE
Mantenga pequeñas las hojas de estilo.
- - - -
SUITABLE
Asegúrese de que el contenido es adecuado para su uso en un contexto móvil.
- - EGYRS: 2.4.6 AA 13.8 P3 y 14.1 P1
TABLES_ALTERNATIVES
Cuando sea posible, utilice una alternativa a la presentación mediante tablas.
- - EGYRS: 1.3.1 A y 1.3.2 A 5.3 P2
TABLES_LAYOUT
No use tablas para disponer el contenido.
EGYRS: 1.3.1 (Técnicas recomendadas) - - 5.3 P2, y 5.4 P2.
TABLES_SUPPORT
No use tablas a menos que sepa que el dispositivo las soporta.
- - - -
TABLES_NESTED
No use tablas anidadas.
Nota: falta en "From WCAG 2.0 to MWBP: Making content that meets Web Content Accessibility Guidelines 2.0 also meet Mobile Web Best Practices"
- - - -
TESTING
Lleve a cabo pruebas en dispositivos reales y también en emuladores.
EGYRS: Conformidad y Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 - - -
THEMATIC_CONSISTENCY
Asegúrese de que el contenido que se proporciona al acceder a una URI produce una experiencia temáticamente coherente cuando se accede desde diferentes dispositivos.
- EGYRS: Pauta 3. - -
URIS
Mantenga cortas las URI de entrada al sitio.
- - - -

Criterios no cubiertos por la accesibilidad

Tras el análisis nos queda que los siguientes son los 18 criterios no cubiertos por las pautas de accesibilidad:

  • AVOID_FREE_TEXT: En lo posible, evite la entrada de texto libre.
  • CACHING: Proporcione información de caché en las respuestas HTTP.
  • CAPABILITIES: Aproveche las capacidades del dispositivo para proporcionar una experiencia de usuario mejorada.
  • CHARACTER_ENCODING_SUPPORT: Asegúrese de que el contenido está codificado utilizando una codificación de caracteres que sabe que es soportada por el dispositivo.
  • CHARACTER_ENCODING_USE: Indique en la respuesta la codificación de caracteres que se está usando.
  • COOKIES: No dependa de que las cookies estarán disponibles.
  • DEFAULT_INPUT_MODE: Especifique un modo de entrada de texto por defecto, idioma y/o formato de entrada, si sabe que el dispositivo lo soporta.
  • EXTERNAL_RESOURCES: Mantenga al mínimo el número de recursos externos enlazados.
  • IMAGES_SPECIFY_SIZE: Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • LARGE_GRAPHICS: No utilice imágenes que no podrán ser renderizadas por el dispositivo. Evite imágenes grandes o de alta resolución excepto cuando en otro caso se perdería información crítica.
  • MINIMIZE: Utilice el marcado de manera escueta y eficiente.
  • MINIMIZE_KEYSTROKES: Mantenga al mínimo el número de pulsaciones de teclas.
  • NO_FRAMES: No use marcos.
  • STYLE_SHEETS_SIZE: Mantenga pequeñas las hojas de estilo.
  • TABLES_SUPPORT: No use tablas a menos que sepa que el dispositivo las soporta.
  • TABLES_NESTED: No use tablas anidadas.
  • URIS: Mantenga cortas las URI de entrada al sitio.

Y de todas ellas hay unas cuantas que, aunque no se consideran requisitos para la conformidad, están cubiertas por lo que podríamos llamar buenas prácticas del diseño web sin más o de atención a ciertos grupos de personas con discapacidad. Por ejemplo, podríamos excluir de la lista:

  • AVOID_FREE_TEXT: En atención a personas con ciertas deficiencias cognitivas se suele facilitar texto por omisión o selectores con respuestas predefinidas que facilitan el rellenar un formulario a todos.
  • CHARACTER_ENCODING_SUPPORT: En general hoy en día se sigue la buena práctica de codificar en UTF8.
  • CHARACTER_ENCODING_USE: Esto lo hará el servidor.
  • LARGE_GRAPHICS: Al tener en cuenta usuarios con conexiones de banda estrecha se tiende a cuidar el peso de los elementos.
  • MINIMIZE_KEYSTROKES: Al igual que la primera va encaminada a ahorrarle al usuario tener que escribir, así que quedaría también cubierta por el buen diseño de formularios y campos de entrada.
  • MINIMIZE: Todos es cuestión de configurar el servidor o utilizar las herrameintas existentes para ello.
  • NO_FRAMES: Hace muchísimos años que casi nadie usa marcos y de todos es sabida la dificultad que presentan para los usuarios de lectores de pantalla.
  • TABLES_NESTED: Aunque no es un requisito para la conformidad, de siempre se ha alentado a simplificar las tablas dado los problemas que pueden suponer para algunos usuarios, máxime si están anidadas.
  • URIS: Sobre cómo deberían ser las URI, Tim Bernes-Lee escribió hace ya muchísimo tiempo, y desde luego nada que ver con esas direcciones larguísimas y supuestamente "amigables para el usuario" que generan alguns CMS y alientan algunos diseñadores. Ahora todo vuelve a su cauce.

Tendríamos 8 criterios más a agregar al saco de criterios cubiertos por la experiencia en diseño desde la perspectiva de la accesibilidad. Quedando, por tanto tan sólo un 17% de los criterios de buenas prácticas para el diseño web móvil sin cubrir. Es decir, los desarrolladores/diseñadores con experiencia en accesibilidad tienen en sus hábitos de trabajo ya lo necesario para cubrir el 83% de los criterios para que su web sea amigable con los dispositivos móviles.
Gráfica que presenta en forma de tarta el resumen de resultados: WCAG 1.0 + WCAG 2.0 = 40 ó 70%, sólo WCAG 1.0 = 2 ó 3%, sentido común = 8 ó 13%, no cubiertas = 10 ó 17%.
Gráfica de resultados del análisis



Criterios conflictivos

De los 10 criterios que no quedan cubiertos, hay 3 que me parecen conflictivos:

  • EXTERNAL_RESOURCES: Mantenga al mínimo el número de recursos externos enlazados.
  • IMAGES_SPECIFY_SIZE: Especifique el tamaño de las imágenes en el marcado, si tienen un tamaño intrínseco.
  • STYLE_SHEETS_SIZE: Mantenga pequeñas las hojas de estilo.

Cuando digo "conflictivos" me refiero a que pueden suponer, lo que algunos, para evitar aplicar los criterios de accesibilidad llaman "una carga excesiva". Naturalmente nadie va a reclamar que eso suponga una carga excesiva, Google manda y todos queremos estar en buenas relaciones con él. Pero el caso es que modificar una web existente para cumplir con esos cuatro criterios puede resultar en un gran dolor de cabeza. Sobre todo si se trata de una web muy antigua. Y es que, el primero supondrá modificar las cabeceras de todas las páginas, mientras que es posible que en nuestro antiguo sitio web tengamos una cabecera para todas ellas y desde allí estemos llamando a varios recursos útiles para el sitio en su conjunto y no sólo para una página en concreto. O definir en cada imagen el tamaño de la misma, cuando por razones, precisamente de adaptabilidad y compatibilidad con diversos tamaños de pantalla, no lo hemos hecho. O hacer lo que Google sugiere sobre las hojas de estilo en Optimize CSS Delivery, cuando ahí mismo advierte que pronto no será necesario utilizar javascripts, pues se podrá hacer mediante el elemento link y cuando el criterio 5.4.10 de las buenas prácticas para el diseño web móvil piden precisamente que "Use of structural markup (see 5.4.3 Structural Elements) contributes to minimizing the size of the markup on a page, as does centralizing the style descriptions using CSS" (el remarcado es mío). Y es más, algunos CMS combinan todos los estilos definidos en varias hojas de estilo (del tema, del autor, etc.) de manera que resulte una única hoja de estilos.

jueves, 15 de diciembre de 2011

En estas fiestas ... ¡Contribuye a hacer la web más accesible!

En estos días en los que el ambiente, la publicidad, la decoración, y todo en general nos invita a la emotividad y a ser generosos, desde el Grupo de Educación y Difusión del W3C-WAI [Education & Outreach Working Group (EOWG)] estamos promoviendo una serie de sugerencias y ejemplos que esperamos animen a todos a contactar con los responsables de aquellas webs en las que encuentren problemas para navegar o comprar en estas fiestas.

Como sabréis, hace años se me ocurrió un sistema, una aplicación; precisamente para facilitar a los usuarios un modo de contactar con los responsables de las webs que, por una parte fuese comprensible para el usuario medio y por otra pudiera comunicar en terminos más técnicos los problemas encontrados. El sistema inicialmente se llamó SPRAW (Servicio Público de Revisión de la Accesibilidad Web), y fue presentado durante las IX Jornadas Sidar, allá por 2005. La aplicación ha pasado por las manos de varios desarrolladores, ha cambiado su nombre a VAPOR, y probablemente debido a que es algo compleja, ya que no se limita a servir a los usuarios sino también a los propios desarrolladores con un sistema, para su época demasiado avanzado, de trabajo colaborativo y en red (lo que hoy conocemos como redes sociales), y con un sistema semántico de confiabilidad y reputación; ha visto retrasada su publicación. La buena noticia es que está casi, casi, preparada, a falta de un buen diseñador que pueda crear una interfaz a su medida. Esperamos compartir la buena nueva el año que viene.

Por lo pronto contamos con las sugerencias mencionadas y, a continuación traduzco los contenidos que hasta el momento hemos agregado en el wiki del grupo del WAI, y que os pueden dar ideas para entradas en vuestros blogs y tweets, animando a todos a leer el documento sobre cómo contactar con los responsables de esas webs que amargan las fiestas a las personas con discapacidad, entre otros.

Promoviendo el contacto con responsables de sitios web inaccesibles

El siguiente contenido es una traducción y localización del que se encuentra originalmente en: http://www.w3.org/WAI/EO/wiki/Promoting_Contact_Orgs_Inaccessible_Sites

Audiencia: Usuarios - Breve (Editor inicial: Jennifer Sutton)

[Para personas con discapacidad] Durante las fiestas, comprar a través de Internet puede ser frustrante para las personas con discapacidad. ¿No te suena familiar algo de esto?. Tienes en mente el regalo perfecto, ...

[Para público en general] Durante las fiestas comprar por Internet puede llegar a ser frustrante para las personas con discapacidad. Imagina cómo te sentirías si tienes en mente el regalo perfecto, ...

... pero entonces, no puedes leer bien, no puedes encontrar lo que buscas en medio de tantos enlaces en la página, no estás seguro de si lo has metido realmente en la cesta, o no puedes comprobarlo por ti mismo. No tiene gracia no poder mantener en secreto el regalo porque no puedes comprarlo sin pedir ayuda. Quejarte en Twitter o Facebook no te ayudará mucho en definitiva. Así que, ¿cómo plantear tus inquietudes de manera constructiva, mantener el espíritu navideño a la vez que ayudas a conseguir que la Web sea más accesible y comenzar a obtener resultados positivos? Intenta visitando estas dos páginas que te darán algunas pautas y ejemplos de mensajes que puedes enviar: en el blog del W3C (en inglés), o el documento completo del WAI (en inglés), o el documento traducido al español.

Audiencia: Usuarios - Extenso (editor inicial: Jennifer Sutton)

(Nota: Invitamos a utilizar este texto palabra por palabra, haciendo referencia a su autor, Jennifer Sutton. Si desea hacer cambios, contacte por favor con Jennifer en jsuttondc@gmail.com)

Cuando navego durante las fiestas, tan sólo quiero encontrar lo que busco y comprarlo sin necesidad de ayuda. Pero a veces, cuando termino de buscar, mi entusiasmo navideño ha desaparecido. Intentar utilizar un sitio inaccesible para comprar un regalo o hacer una donación en nombre de un ser querido puede llevar un tiempo que yo simplemente no tengo durante estas ajetreadas fiestas.

Pero si dedico un pequeño tiempo extra a informar sobre mis experiencias a las organizaciones responsables de los sitios que visito, creo que mi esfuerzo hará que la Web sea un lugar mejor el año que viene.

Como hago mi lista de compras y apunto los enlaces de los sitios que pienso visitar, estoy añadiendo ese par de enlaces a mi colección para tenerlos a mano. También he creado por adelantado un borrador o dos de email, para que me sirvan para informar sobre mi experiencia de compra rápidamente, tanto para las buenas como para las que resulten más difícil de lo que desearía. ¿Por qué no te unes a mí y comienzas tu Año Nuevo de manera positiva ayudando a que la Web sea un lugar más accesible?.

Encontrarás pistas sobre cómo informar a los sitios web en estas dos páginas, creadas para ti por la iniciativa de accesibilidad del Consorcio para la Web (W3C-WAI, por sus siglas en inglés): Una entrada de blog, en http://bit.ly/inaccessible1 y un documento en http://bit.ly/inaccessible2 (En español en: http://goo.gl/V6CTO.

Audiencia: Desarrolladores y responsables de una web (editor inicial: Sharron Rush)

Si vendes bienes y servicios a través de Internet, tienes un mercado ávido de más de 750 millones de personas al rededor del mundo. Según la revista Fortune, tan sólo en los Estados Unidos este grupo cuenta con un ingreso total que supera el billón de dólares y con un poder adquisitivo discrecional de 220.000 millones de dólares.

Tan ideal como parece, muchos minoristas en línea no logran llegar a este valioso mercado debido a que sus sitios web no son accesibles para el grupo descrito - las personas con discapacidad. Este grupo amplio y creciente de clientes es probable que pierda el interés cuando los campos de formulario no están etiquetados, los elementos gráficos no están descritos, o cuando el siguiente paso en un proceso de compra se muestra en un cuadro de diálogo que no puede ser percibido por un producto de apoyo (ayuda técnica). Estas y otras barreras creadas por el diseño pueden hacer penosas las compras en línea para los compradores potenciales con discapacidad.

Si tu clientela está frustrada, tú necesitas saberlo. La Iniciativa para la Accesibilidad Web del W3C ofrece un recurso para ayudarles a comunicártelo de manera útil y constructiva. Considera la posibilidad de ofrecer un enlace a ese recurso en tus páginas, para los clientes que encuentren barreras a la hora de comprar.

La guía se llama «Cómo contactar con organizaciones sobre sus sitios web inaccesibles» y puede ayudar a tus clientes potenciales a describir áreas problemáticas específicas. Abre los canales de comunicación a los clientes potenciales con discapacidad. Puedes hacer que sus fiestas sean más felices y darte a ti mismo el regalo de un nuevo cliente que seguramente volverá. ¡Que tus fiestas sean brillantes!

Audiencia: Estados Miembro de Naciones Unidas (editor inicial: Vicki Menezes Miller)

Accesibilidad web, mírala desde este ángulo: Ayuda a hacer la web más accesible durante estas fiestas. La Convención Internacional de Derechos de las Personas con Discapacidad, de Naciones Unidas, en su artículo 9(g) exige que los sitios web sean accesibles para todos. La Iniciativa para la Accesibilidad Web del W3C proporciona una gran cantidad de recursos y orientación, este mes: Si quieres contactar con una entidad para sugerirle mejoras en su accesibilidad web, ve a: http://bit.ly/inaccessible2 (En español: http://goo.gl/V6CTO)

Audiencia: Entidades Públicas (editor inicial: Wayne)

Tu departamento ha trabajado duro en el sitio web. Haz dejado de lado el presupuesto y has contratado buena gente. Ahora ofrecéis la mayoría de los servicios en línea. La web también informa a la gente sobre las clases de servicios y eventos que ofrece la institución. Direcciones, calendarios y toda la información clave se difunde mediante vuestra presencia en línea. Le ahorras a la gente horas de viaje. Estás orgulloso y así debe ser.

Es posible que no te hayas dado cuenta, pero muchas personas con discapacidad visitarán el sitio. Se trata de un amplio y creciente grupo de usuarios y es probable que esos visitantes pierdan oportunidades importantes en tu institución debido a errores fáciles de arreglar que obstruyen su acceso. Controles de formulario que aparecen sin etiquetas, elementos gráficos que no tienen una descripción en texto, o el paso en un proceso de registro que se presenta en un cuadro de diálogo que no puede ser percibido por un producto de apoyo (ayuda técnica). Esas y otras barreras del diseño pueden hacer penoso o imposible el uso a los usuarios con discapacidad. Tu sitio web puede estar bloqueando el acceso a servicios públicos que están dirigidos a todos, incluso a las personas con discapacidad.

Si tu público está frustrado, tú necesitas saberlo. La Iniciativa para la Accesibilidad Web del W3C ofrece un recurso para ayudarles a comunicártelo de manera útil y constructiva. Considera la posibilidad de ofrecer un enlace a ese recurso en tus páginas, para aquellos que encuentren barreras a la hora de navegar.

La guía se llama «Cómo contactar con organizaciones sobre sus sitios web inaccesibles» y puede ayudar a tu público a describir áreas problemáticas específicas. Abre los canales de comunicación a tus públicos potenciales con discapacidad. Puedes hacer que sus fiestas sean más felices y darte a ti mismo el regalo de un nuevo usuario que seguramente volverá. ¡Que tus fiestas sean brillantes!

Ideas para tweets

  • Si un sitio inaccesible te frustra durante las fiestas, aquí encontrarás qué puedes hacer: http://goo.gl/V6CTO
  • ¿Cansado de gritarle a tu ordenador porque un sitio es inaccesible? Esta entrada de blog describe lo que puedes hacer: http://goo.gl/V6CTO
  • ¿Has usado los mensajes de ejemplo para contactar con una entidad sobre su sitio inaccesible? Aquí puedes verlos: http://goo.gl/V6CTO
  • En estas fiestas, ayuda a hacer la web más accesible. Contacta con una entidad para sugerirle mejoras: http://goo.gl/V6CTO
  • ¿Has encontrado un sitio web inaccesible? ¡Díselo! Consejos y emails de ejemplo: blog http://bit.ly/inaccessible1 & doc.: http://goo.gl/V6CTO #a11y

jueves, 18 de agosto de 2011

Redefiniendo la accesibilidad

¿Cómo percibe la gente el concepto de accesibilidad web? Esa es la pregunta que se hacen una serie de investigadores europeos, Giorgio Brajnik, Simon Harper, Markel Vigo, y Yeliz Yesilada; a la que esperan dar respuesta mediante una encuesta dirigida a personas relacionadas con este tema.

La encuesta sobre el concepto de accesibilidad (en inglés y con algúna que otra barrera para ciertos usuarios), es bastante amplia y, entre otras cosas, sugiere una serie de definiciones que quien responde ha de valorar.

Al responder la encuesta, me ha parecido que ninguna de las propuestas se ajusta realmente a lo que significa la accesibilidad, ya que ninguna de ellas, ni ninguna de las existentes, tienen en cuenta la responsabilidad de parte del usuario. Y muy pocas tienen en cuenta que la accesibilidad no existe por sí misma, sólo existe en el momento en que interactúen una serie de elementos: código, contenido, agente de usuario, y el usuario mismo con sus características técnicas y personales.

La accesibilidad es un "koan"

La cuestión de la accesibilidad me recuerda a uno de los más conocidos "koan", aquél en que el maestro choca sus palmas y pregunta: «Este es el sonido de dos manos, ¿cuál es el sonido de una sola mano?»; o al viejo problema filosófico de: ¿Hace rúido el árbol que cae cuando no hay nadie para escucharlo?.

Y es que la accesibilidad sólo se da, se consigue, no sólo haciendo una página de una cierta manera. Es necesario que el usuario ponga de su parte, que conozca cómo configurar las herramientas que utiliza para cubrir sus necesidades (Sistema operativo, navegador y ayudas técnicas, incluidas).

La accesibilidad sólo existe o nó, en el momento en que un usuario interactúa con un producto o servicio web. Y personalmente creo que la la responsabilidad sobre la accesibilidad la hemos de repartir a partes casi iguales entre el diseñador/desarrollador y el usuario. Porque muchas veces las limitaciones se deben a que el usuario no se ha tomado la molestia de configurar adecuadamente sus agentes de usuario, o no se ha molestado en actualizarlos, o no se ha molestado siquiera en prestar atención a los elementos de ayuda existentes en la página.

Las definiciones propuestas

En la encuesta se proponen una serie de definiciones y se pide que se indique qué te gusta y qué no te gusta de cada definición, y que sugieras cómo mejorarlas. Veamos esas definiciones y mis propuestas:

«The removal of all technical barriers to effective interaction.»

Esta definición me parece errada porque supone que la accesibilidad es una cuestión meramente técnica, y evidentemente no es así.

En su lugar propondría, aunque no me gusta mucho: «La eliminación de todas las barreras técnicas, para la comprensión y la percepción, para una interacción eficaz.»

«Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.»

Esta definición contiene una idea importante, la de que no se trata de conseguir meros usuarios sino que las personas puedan contribuir a la web. Pero falla en limitar la accesibilidad a las necesidades de las personas con discapacidad.

En su lugar propondría: «Web accessibility means that people with or without disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web»

«A website is accessible if it it is effective, efficient and satisfactory for more people in more situations.»

Esta es la definición que se encuentra más cerca de la que hace la norma ISO TS 16071, no limitando la accesibilidad a las necesidades de las personas con discapacidad y centrándose en la eficiencia, eficacia y satisfacción del usuario. Pero a diferencia de ella, en la que se indica como objetivo alcanzar al "más amplio rango de capacidades", aquí se habla de mayoría o "más personas", lo que significa bien poco. No creo que mejore en nada la definción hecha en la norma ISO.

«Technology is accessible if it can be used as effectively by people with disabilities as by those without.»

Nuevamente aquí se pone el acento en las personas con discapacidad y se limita al uso.

«The extend to which a product/website can be used by specified users with specified disabilities to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.»

Esta claramente es una definición errada para accesibilidad. Sería adecuada para definir la usabilidad para personas con discapacidad.

Mi propuesta de definición

Finalmente, en la encuesta se pide que si no te gusta ninguna de las anteriores, proporciones la que tú usuarías. Y en ese momento se me ocurrió la siguiente, partiendo de la definición hecha por Tim Bernes Lee The art of ensuring that, to as large an extent as possible, facilities (such as, for example, Web access) are available to people whether or not they have impairments of one sort or another., que me gusta mucho porque pone el acento en que se trata de un arte y no de una mera cuestión técnica. Así que propuse (en inglés, o algo que se le parece):

Accessibility is the art of giving the user the ability to understand, navigate and interact efficiently, effectively and successfully, regardless their personal or technical capacities.

Pero como decía antes, un objetivo fundamental de la accesibilidad web es facilitar la participación de todos, conseguir que todos podamos contribuir al desarrollo de la web, y en ese sentido creo que habría que agregarle alguna que otra palabra para que quede explícitamente declarado. Entonces podríamos tener la siguiente definición:

Accesibilidad es el arte de facilitar al usuario la posibilidad de comprender, navegar, interactuar y contribuir; de manera eficiente, eficaz y satisfactoria, independientemente de sus capacidades personales o técnicas.

No sé, me parece que aún no es una definición "redonda", habrá que seguir pensando ...

miércoles, 10 de agosto de 2011

Aciertos, errores, y contradicciones en la Ley 26/2011

Desde mi punto de vista, son muchos los aciertos, pero francamente sorprendentes los fallos y contradicciones resultantes de esta nueva ley: «Ley 26/2011 de 1 de agosto, de adaptación normativa a la Convención Internacional sobre los Derechos de las Personas con Discapacidad».

Como sabemos, la «Convención Internacional sobre los Derechos de las Personas con Discapacidad» y su Protocolo Facultativo fueron aprobados el 13 de diciembre de 2006 por la Asamblea General de las Naciones Unidas (ONU). Ambos tratados internacionales recogen los derechos de las personas con discapacidad, así como las obligaciones de los Estados Partes de promover, proteger y asegurar tales derechos.

El artículo 4 de la Convención, en virtud del cual los Estados Partes se comprometen a adoptar todas las medidas legislativas, administrativas y de otra índole que sean pertinentes para asegurar el pleno ejercicio de todos los derechos humanos y las libertades fundamentales de las personas con discapacidad sin discriminación alguna por motivos de discapacidad; fundamenta la necesidad de modificar las leyes existentes en los países que la ratifican.

España ratificó la Convención y su Protocolo Facultativo el 21 de abril de 2008, y entró en vigor el 3 de mayo de ese mismo año. A partir de este momento, y conforme a lo establecido en el apartado primero del artículo 96 de la Constitución Española de 1978, forma parte del ordenamiento interno, por lo que resulta necesaria la adaptación y modificación de diversas normas para hacer efectivos los derechos que la Convención recoge.

Nuestra Constitución, en su artículo 49 regula la atención a las personas con discapacidad, pero tal como se dice en esta misma ley: "se inspiró en el modelo médico o rehabilitador, predominante en el momento de su aprobación, el cual consideraba la discapacidad como un problema de la persona, causado directamente por una enfermedad, accidente o condición de su salud, que requiere asistencia médica y rehabilitadora, en forma de un tratamiento individualizado prestado por profesionales. La presente Ley, de acuerdo con la Convención, supera este modelo médico asumiendo la perspectiva social y de derechos y capacidades, que configura la discapacidad como un complejo conjunto de condiciones, muchas de las cuales están originadas o agravadas por el entorno social."

Esta nueva ley, por tanto, se supone que "ahonda en el modelo social de la discapacidad, cuyo precedente inmediato sería la Ley 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad, pero da un decidido impulso reformador en el sentido de salvaguardar los derechos de tales personas con el objetivo de favorecer la toma de decisiones en todos los aspectos de su vida, tanto personal como colectiva, avanzar hacia la autonomía personal desinstitucionalizada y garantizar la no discriminación en una sociedad plenamente inclusiva".

Según leemos en el preámbulo: "Esta norma ha sido informada favorablemente por el Consejo Nacional de la Discapacidad, en el que participan las organizaciones representativas de personas con discapacidad y de sus familias."

Asombro desde el artículo 1

El primer artículo se centra en modificar la Ley 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad (LIONDAU), y al modificar el apartado 2 de dicho artículo dice:

«2. Son personas con discapacidad aquellas que presenten deficiencias físicas, mentales, intelectuales o sensoriales a largo plazo que, al interactuar con diversas barreras, puedan impedir su participación plena y efectiva en la sociedad, en igualdad de condiciones con los demás. Las medidas de defensa, de arbitraje y de carácter judicial, contempladas en esta Ley serán de aplicación a las personas con discapacidad, con independencia de la existencia de reconocimiento oficial de la situación de discapacidad o de su transitoriedad. En todo caso, las Administraciones públicas velarán por evitar cualquier forma de discriminación que afecte o pueda afectar a las personas con discapacidad.

Y yo me pregunto: ¿En qué quedamos?. ¿Cómo es posible que hoy en día, y supuestamente habiendo leído la Convención, y siendo revisada por el Consejo Nacional de la Discapacidad, se consigne tal definición; absolutamente contraria a la definición recogida en la CIF (véase, por ejemplo: Aplicación de la CIF a la comunicación en la web) y en la Convención misma?.

Ni la discapacidad depende de la existencia de una deficiencia, ni la deficiencia matemáticamente supone una discapacidad. Menos mal que, al menos, han recogido la posibilidad de que la discapacidad esté o no reconocida oficialmente y de que sea o no transitoria.

No es mi intención analizar todo el alcance de la ley, quiero limitarme a lo más general y a lo específicamente relacionado con la accesibilidad en la Sociedad de la Información. Creo que en los aspectos relacionados con otros órdenes la nueva ley supone un avance (excepto por la, ya mencionada, definición de discapacidad).

Nuevos artículos

La ley añade dos nuevos artículos a la LIONDAU:

«Artículo 10 bis. Igualdad de trato en acceso a bienes y servicios.
  1. Todas las personas físicas o jurídicas que, en el sector público o en el privado, suministren bienes o servicios disponibles para el público, ofrecidos fuera del ámbito de la vida privada y familiar, estarán obligadas, en sus actividades y en las transacciones consiguientes, al cumplimiento del principio de igualdad de oportunidades de las personas con discapacidad, evitando discriminaciones, directas o indirectas, por razón de discapacidad.
  2. Lo previsto en el apartado anterior no afecta a la libertad de contratación, incluida la libertad de la persona de elegir a la otra parte contratante, siempre y cuando dicha elección no venga determinada por su discapacidad.
  3. No obstante lo dispuesto en los apartados anteriores, serán admisibles las diferencias de trato en el acceso a bienes y servicios cuando estén justificadas por un propósito legítimo y los medios para lograrlo sean adecuados, proporcionados y necesarios.
»

«Artículo 21. Consecuencias del incumplimiento de las prohibiciones.
Sin perjuicio de otras acciones y derechos contemplados en la legislación civil y mercantil, la persona que, en el ámbito de aplicación del artículo 10 bis sufra una conducta discriminatoria por razón de discapacidad, tendrá derecho a indemnización por los daños y perjuicios sufridos.»

Es decir, que ahora, las personas tendrán derecho a demandar indemnizaciones cuando se sientan discriminadas en razón de su discapacidad. Y esto puede venir muy bien, porque será una aliciente para que las personas con discapacidad denuncien tales situaciones.

Se modifica la Ley 49/2007, de 26 de diciembre, de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.

La modificación en lo que afecta a las posibles sanciones por discriminación debida a barreras a la accesibilidad en las webs, se centra en añadir la posibilidad de que:

Cuando las infracciones sean graves o muy graves, los órganos competentes propondrán, además de la sanción que proceda, la prohibición de concurrir en procedimientos de otorgamiento de ayudas oficiales, consistentes en subvenciones o cualesquiera otras ayudas en el sector de actividad, en cuyo ámbito se produce la infracción, por un período máximo de un año, en el caso de las graves, y de dos, en el caso de las muy graves.

Puesto que las infracciones por inaccesibilidad en la web tienen el carácter de graves, el período máximo al que pueden verse limitados para percibir subvenciones se limita a un año.

Modificación de la Ley 23/1998, de 7 de julio, de Cooperación Internacional para el Desarrollo

La novedad en la modificación está en que se obliga a que los instrumentos de cooperación sean accesibles para las personas con discapacidad:

Dos. Se añade un apartado 2 al artículo 9, con la siguiente redacción: «2. Estos instrumentos deberán ser inclusivos y accesibles para las personas con discapacidad.»

Esto implica que las campañas de divulgación, servicios de información, programas formativos, y de capacitación, han de cumplir con los requisitos de accesibilidad. Y esta es una excelente noticia.

Accesibilidad de las redes sociales: Modificación de la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico

Se añade un nuevo apartado en la Disposición Adiconal Quinta:

«Disposición adicional quinta. Accesibilidad para las personas con discapacidad y de edad avanzada a la información proporcionada por medios electrónicos.
Las páginas de Internet que sirvan de soporte o canal a las redes sociales en línea, desarrolladas por entidades cuyo volumen anual de operaciones, calculado conforme a lo establecido en la normativa del Impuesto sobre el Valor Añadido, exceda de 6.101.121,04 euros, deberán satisfacer, a partir del 31 de diciembre de 2012, como mínimo, el nivel medio de los criterios de accesibilidad al contenido generalmente reconocidos. Excepcionalmente, esta obligación no será aplicable cuando una funcionalidad o servicio no disponga de una solución tecnológica que permita su accesibilidad.»

Esto implica que aquellas entidades propietarias de redes sociales, con un volumen de negocio superior a los 6 millones de euros, deberán cumplir con el nivel de accesibilidad Doble A, desde el 1 de enero de 2013.

Personalmente no entiendo a qué se debe que las redes sociales más pequeñas no hayan de cumplir con el criterio, pero en fin, siempre es un avance el que, al menos, se le exija a las más grandes.

En resumen, avanzamos pues al menos se mantienen los plazos anteriores, se amplía la exigencia de la accesibilidad explícitamente a las redes sociales y a los instrumentos de cooperación internacional, se reconoce el derecho a indemnización por los daños y perjuicios y se añade a la sanción que pueda ser impuesta por discriminación, la prohibición de recibir subvenciones durante un año, para aquél que haya discriminado por razón de discapacidad.