En la siguiente lista de reproducción ¿Qué es un CAPTCHA? explico el orígen de los captchas, su uso actual, sus problemas de accesibilidad y su futuro:
miércoles, 24 de julio de 2013
Captchas alternativos
En la página tedd's CAPTCHA's se presentan algunos captchas alternativos muy interesantes. Sin embargo, todos presentan algún problema y siguen sin ser accesibles.
En la siguiente lista de reproducción ¿Qué es un CAPTCHA? explico el orígen de los captchas, su uso actual, sus problemas de accesibilidad y su futuro:
En la siguiente lista de reproducción ¿Qué es un CAPTCHA? explico el orígen de los captchas, su uso actual, sus problemas de accesibilidad y su futuro:
lunes, 22 de julio de 2013
La accesibilidad web en Ontario
El artículo de la Wikipedia sobre Ontario dice:
En el año 2005 promulgó la ley ACCESSIBILITY FOR ONTARIANS WITH DISABILITIES ACT, 2005. Posteriormente, promulgó la regulación ONTARIO REGULATION 191/11 INTEGRATED ACCESSIBILITY STANDARDS que tiene un apartado dedicado a la accesibilidad de los sitios y contenido web.
Según explican en Information and Communications, todas las empresas de 50 o más empleados, sean de lo que sean, están obligadas a que sus sitios web sean accesibles según WCAG 2.0.
Para lograr este objetivo, se han establecido unos plazos que se explican en Make your website accessible:
Son unos plazos muy razonables, que permiten una cómoda adaptación (en el 2021 seguramente ya estaremos utilizando HTML7 u 8).
Y mientras tanto, en España seguimos con nuestra legislación que se hizo "a todo trapo", con unos plazos que eran muy difíciles o costosos de cumplir, que impone multas de hasta 1.000.000 de euros en el caso de faltas muy graves, pero que nadie sabe que se haya aplicado alguna vez (ni la máxima ni la mínima sanción).
Ontario (pronunciado en inglés [ɒn'tɛəɹi.oʊ] y en español [on'taɾjo]) es una de las diez provincias de Canadá, y la más poblada del país (cerca de un tercio de la población canadiense vive en Ontario). En esta provincia se localizan tanto la mayor ciudad canadiense, Toronto, como Ottawa, la capital del país. También es la segunda mayor provincia del país en términos de área, sólo por detrás de Quebec.Ontario es la provincia más importante de Canadá, por tanto, es es relevante la legislación en materia de accesibilidad web que posee, una de las más avanzadas.
En el año 2005 promulgó la ley ACCESSIBILITY FOR ONTARIANS WITH DISABILITIES ACT, 2005. Posteriormente, promulgó la regulación ONTARIO REGULATION 191/11 INTEGRATED ACCESSIBILITY STANDARDS que tiene un apartado dedicado a la accesibilidad de los sitios y contenido web.
Según explican en Information and Communications, todas las empresas de 50 o más empleados, sean de lo que sean, están obligadas a que sus sitios web sean accesibles según WCAG 2.0.
Para lograr este objetivo, se han establecido unos plazos que se explican en Make your website accessible:
- A partir de 2014, todo los sitios y contenido web nuevo debe cumplir WCAG 2.0 nivel A.
- A partir de 2021, todo los sitios y contenido web publicado a partir del 1 de enero de 2012 debe cumplir con WCAG 2.0 nivel AA.
Son unos plazos muy razonables, que permiten una cómoda adaptación (en el 2021 seguramente ya estaremos utilizando HTML7 u 8).
Y mientras tanto, en España seguimos con nuestra legislación que se hizo "a todo trapo", con unos plazos que eran muy difíciles o costosos de cumplir, que impone multas de hasta 1.000.000 de euros en el caso de faltas muy graves, pero que nadie sabe que se haya aplicado alguna vez (ni la máxima ni la mínima sanción).
viernes, 19 de julio de 2013
Mejora de la accesibilidad para las personas con dislexia
En el artículo This young scientist is using technology to help dyslexics nos cuentan que Luz Rello, una estudiante de doctorado de la Universitat Pompeu Fabra está estudiando cómo mejorar la accesibilidad de las páginas web de cara a las personas con dislexia y ha recibido el European Young Researchers' Award 2013.
Es muy interesante todo lo que se cuenta en el artículo... que incluye un pequeño secreto.
Es muy interesante todo lo que se cuenta en el artículo... que incluye un pequeño secreto.
jueves, 18 de julio de 2013
La mala ortografía es mala, lo mires como lo mires
Hace un año escribí la entrada La buena ortografía ayuda a la accesibilidad web, en la que explicaba que la mala ortografía puede ser una barrera de accesibilidad.
Como en otras ocasiones, se vuelve a demostrar que un problema de accesibilidad que en principio puede parecer que sólo perjudica a unos pocos (las personas con discapacidad), en realidad perjudica a todo el mundo. El artículo La mala ortografía le cuesta caro a las ventas por internet dice:
Un empresario de internet asegura que la mala ortografía en inglés le cuesta millones de libras al Reino Unido.
Charles Duncombe asegura que un análisis de las cifras de un sitio web con faltas de ortografía reveló que esto puede reducir las ventas en línea hasta en 50%.
Duncombe insiste que a la hora de contratar personal se ha visto sorprendido "por la mala calidad de su inglés escrito".
Así que asegura que el gran problema para las empresas en línea no es la tecnología, sino la búsqueda de personal que sepa escribir correctamente.
Quizás un 50% es un poco exagerado, y no hay que creer la palabra de una sola persona, pero seguro que la mala ortografía sí que tiene influencia en la credibilidad de un sitio web, lo cual puede impactar en que los visitantes regresen o realicen algunas compras en un sitio web.
martes, 16 de julio de 2013
Petición para que longdesc sea visible en Google Chrome
Emmanuelle Gutiérrez nos avisa en un mensaje publicado en la lista de correo accesoweb que existe una petición para que el atributo longdesc sea visible en Google Chrome y sea accesible para los productos de apoyo.
Desgraciadamente, el atributo longdesc había desaparecido de HTML5, pero gracias a una extensión para la descripción de las imágenes que ha desarrollado el W3C, ha regresado. Además, recientemente, Mozilla anunció que va a incorporar en Firefox el soporte del atributo longdesc. Y si se incorpora el soporte del atributo longdesc a Chrome también estará disponible en el navegador Opera, porque ahora Opera se basa en el proyecto Chromium y por tanto Chrome y Opera comparten el mismo intérprete de páginas web.
¿Por qué es importante que los navegadores faciliten el uso del atributo longdesc?
El atributo longdesc siempre ha estado ahí, pero como los navegadores web no permitían su uso, era desconocido para la mayoría de los desarrolladores web, y aquellos desarrolladores web que sí que lo conocían, como no lo podían probar, al final no lo usaban.
Por tanto, es muy importante que los navegadores web faciliten el uso del atributo longdesc, ya que aumentará su visibilidad, los desarrolladores web serán más conscientes de su existencia y utilidad, y es muy probable que aumente su uso, lo que repercutirá en una mejora de la accesibilidad web.
Por último, un ejemplo de uso del atributo longdesc con imágenes complejas. Si se quiere comprobar su funcionamiento, se puede hacer con el navegador Mozilla Firefox y su complemento Longdesc (dentro de poco el propio navegador incorporará esta opción y ya no será necesario instalar este complemento).
Y por último, el W3C ha lanzado el "last call" para la revisión de HTML5 Image Description Extension (longdesc). Se pueden mandar comentarios hasta el 16 de septiembre.
Desgraciadamente, el atributo longdesc había desaparecido de HTML5, pero gracias a una extensión para la descripción de las imágenes que ha desarrollado el W3C, ha regresado. Además, recientemente, Mozilla anunció que va a incorporar en Firefox el soporte del atributo longdesc. Y si se incorpora el soporte del atributo longdesc a Chrome también estará disponible en el navegador Opera, porque ahora Opera se basa en el proyecto Chromium y por tanto Chrome y Opera comparten el mismo intérprete de páginas web.
¿Por qué es importante que los navegadores faciliten el uso del atributo longdesc?
El atributo longdesc siempre ha estado ahí, pero como los navegadores web no permitían su uso, era desconocido para la mayoría de los desarrolladores web, y aquellos desarrolladores web que sí que lo conocían, como no lo podían probar, al final no lo usaban.
Por tanto, es muy importante que los navegadores web faciliten el uso del atributo longdesc, ya que aumentará su visibilidad, los desarrolladores web serán más conscientes de su existencia y utilidad, y es muy probable que aumente su uso, lo que repercutirá en una mejora de la accesibilidad web.
Por último, un ejemplo de uso del atributo longdesc con imágenes complejas. Si se quiere comprobar su funcionamiento, se puede hacer con el navegador Mozilla Firefox y su complemento Longdesc (dentro de poco el propio navegador incorporará esta opción y ya no será necesario instalar este complemento).
Y por último, el W3C ha lanzado el "last call" para la revisión de HTML5 Image Description Extension (longdesc). Se pueden mandar comentarios hasta el 16 de septiembre.
Mejora de la accesibilidad web de cara a las personas mayores
Improving Web Accessibility for the Elderly es una presentación que realizó Roger Hudson en CSUN 2011.
En su blog podemos encontrar el artículo Mature Age ICT Users Survey 2 en el que explica la investigación en la que se basa esta presentación.
En la siguiente imagen podemos ver los principales problemas que declaran las personas mayores que encuentran cuando navegan por la Web. Se distinguen dos grupos: las personas que respondieron a la encuesta a través de un formulario online y las que respondieron "cara a cara".
En su blog podemos encontrar el artículo Mature Age ICT Users Survey 2 en el que explica la investigación en la que se basa esta presentación.
En la siguiente imagen podemos ver los principales problemas que declaran las personas mayores que encuentran cuando navegan por la Web. Se distinguen dos grupos: las personas que respondieron a la encuesta a través de un formulario online y las que respondieron "cara a cara".
lunes, 15 de julio de 2013
Accesibilidad de los formularios
Muy interesante el tutorial Accessible Forms, que explica paso por paso cómo crear formularios accesibles. Entre otras cosas, explica:
- La importancia de etiquetar los controles con label.
- La forma de etiquetar los distintos controles.
- El agrupamiento de controles con fieldset y legend.
- El uso del atributo title.
- Algunos temas de usabilidad de formularios.
viernes, 12 de julio de 2013
Treinta consejos para mejorar la accesibilidad web
El artículo 30 Web Accessibility Tips presenta una lista de treinta consejos para mejorar la accesibilidad web:
- Add proper alt text to images.
- Use headings properly.
- Create accessible PDFs.
- Know when to use PDF.
- Use ARIA landmarks.
- Add labels to form fields.
- Group related form fields together and assign a single prompt that they all share.
- Markup tables appropriately.
- Identify language of text.
- Use a color contrast checker.
- Avoid using tiny fonts.
- Respect white space (between lines, between paragraphs).
- Provide visible indication of focus, especially for keyboard users.
- Use text, not pictures of text.
- Think twice about the words you choose.
- Caption video.
- Describe video.
- Provide a transcript.
- Choose media players that support accessibility.
- Choose a dropdown menu system that works for all users.
- Choose JavaScript widgets that support accessibility.
- Test JavaScript widgets - don't assume they work for everyone.
- Choose Learning Management Systems (LMS) and Content Management Systems (CMS) that support accessibility.
- Test web pages with a keyboard.
- Test pages with high contrast color schemes.
- Test pages with assistive technologies.
- Test pages on mobile devices.
- Ask vendors specific questions about the accessibility of their products.
- Demand accessibility!
- Get involved!
jueves, 11 de julio de 2013
Introducción a ARIA
Un artículo que explica de forma muy sencilla qué es ARIA y cómo se puede usar: ARIA and Progressive Enhancement.
Lo más interesante del artículo es la comparativa de soporte de diferentes características de ARIA en diferentes lectores de pantalla (ZoomText, JAWS, Window-Eyes, NVDA y VoiceOver):
Muy importante, este artículo es de noviembre de 2010, así que se supone que las versiones actuales de los lectores de pantalla deben soportar más características.
Lo más interesante del artículo es la comparativa de soporte de diferentes características de ARIA en diferentes lectores de pantalla (ZoomText, JAWS, Window-Eyes, NVDA y VoiceOver):
Muy importante, este artículo es de noviembre de 2010, así que se supone que las versiones actuales de los lectores de pantalla deben soportar más características.
miércoles, 10 de julio de 2013
El problema que tiene mucha gente
Unfortunately web content accessibility is being increasingly viewed solely from the perspective of how well a site complies with WCAG 2 rather than how well people with disabilities can access the content.Traducción:
Por desgracia, la accesibilidad de los contenidos web cada vez se ve más exclusivamente desde la perspectiva de lo bien que un sitio cumple con las WCAG 2 en lugar de como la gente con discapacidad puede acceder al contenido.Roger Hudson, Accessibility: More than WCAG compliance - CSUN2013 Talk
martes, 9 de julio de 2013
Consejos para la accesibilidad en dispositivos móviles de la BBC
Hace unos días se publicó la noticia Draft BBC Mobile Accessibility Standards and Guidelines. La BBC ha publicado Mobile Accessibility Guidelines v0.7, unos consejos para mejorar la accesibilidad del contenido destinado a ser consumido con dispositivos móviles.
lunes, 8 de julio de 2013
Denuncia de unos estudiantes contra la Universidad de Montana
En septiembre de 2012 se publicó la noticia Disabled UM students file complaint over inaccessible online courses, en la que se cuenta que se ha presentado una denuncia contra la Universidad de Montana porque un estudiante ciego es discriminado y no puede acceder a los materiales de estudio. En concreto, las alegaciones de la denuncia son:
- Inaccessible class assignments and materials on the learning management system, Moodle.
- Inaccessible live chat and discussion board functions in the learning management system, Moodle.
- Inaccessible documents that are scanned images on webpages and websites.
- Inaccessible videos, and videos in Flash format, that are not captioned.
- Inaccessible library database materials.
- Inaccessible course registration through a website, Cyber Bear.
- Inaccessible classroom clickers.
viernes, 5 de julio de 2013
Building Accessible Websites, libro gratuito
El libro Building Accessible Website, de Joe Clark, que fue publicado en el año 2003, está disponible de forma gratuita y en formato HTML porque su autor recuperó sus derechos: Building Accessible Website Serialization.
El autor avisa de que algunos consejos quizás ya no sean aplicables, así que hay que leer este libro con cuidado y de forma crítica.
El autor avisa de que algunos consejos quizás ya no sean aplicables, así que hay que leer este libro con cuidado y de forma crítica.
jueves, 4 de julio de 2013
Aplicación de WCAG 2.0 a cosas que no son páginas web
WCAG 2.0 es agnóstico respecto a la tecnología, lo que significa que se puede emplear con tecnologías distintas a la Web.
¿Cómo? El documento Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies explica cómo se puede hacer.
¿Cómo? El documento Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies explica cómo se puede hacer.
miércoles, 3 de julio de 2013
Libro: Pro HTML5 Accessibility
Pro HTML5 Accessibility es un libro de la editorial Apress, una editorial que publica títulos de una excelente calidad.
El contenido de este libro es:
El contenido de este libro es:
- Introduction to HTML5 Acessibility
- Understanding Disability and Assistive Technology
- JavaScript Isn't a Dirty Word, and ARIA Isn't Just Beautiful Music
- API and DOM
- HTML5, the New Semantics and New Approaches to Document Markup
- Images, Rich Media, Audio and Video in HTML 5
- HTML5 and Accessible Data Tables
- HTML5 and Accessible Forms
- HTML5, Usability and User-Centered Design
- Tools, Tips, and Tricks: Assessing Your Acessible HTML5 Project
- WCAG 2.0 Client-Side Scripting Techniques
- Definition of WAI-ARIA Roles
martes, 2 de julio de 2013
IndieUI
Independent User Interface (IndieUI) es una nueva iniciativa de WAI que tiene como objetivo facilitar el desarrollo de aplicaciones preparadas para ser compatibles con diferentes dispositivos y contextos de uso.
Por ejemplo, el siguiente gráfico representa diferentes formas de lanzar el mismo evento, una solicitud de desplazamiento (scroll) en un interfaz gráfico:
Por ejemplo, el siguiente gráfico representa diferentes formas de lanzar el mismo evento, una solicitud de desplazamiento (scroll) en un interfaz gráfico:
lunes, 1 de julio de 2013
Cómo elegir una herramienta automática de evaluación de la accesibilidad
Hace unos días, Karl Groves publicó en su blog el artículo Choosing an Automated Accessibility Testing Tool: 13 Questions you should ask. En este artículo explica 13 preguntas/factores que hay que tener en cuenta a la hora de elegir una herramienta automática de evaluación de la accesibilidad:
- Is the tool user-friendly?
- Does the tool provide high quality, reliable results?
- Is the tool capable of testing the DOM?
- Does it offer the ability to spider?
- Does it offer the ability to test uploaded files and/ or source code entered directly?
- Does it offer the ability to perform continuous monitoring?
- Is the tool configurable so that it does not re-test pages which have not changed?
- Does it provide clear, easy to understand manual test guidance?
- Can the tool be configured to support the specific testing needs of the organization?
- Is the tool capable of reporting results in a way that separates common issues from unique ones?
- Can it integrate with existing QA tools and processes?
- Does it support the accessibility standards your organization has committed to supporting?
- Does it offer direct access to modify or extend test logic?
viernes, 28 de junio de 2013
Informe eEspaña 2013
El pasado lunes 24 de junio se presentó el Informe eEspaña 2013, elaborado por la Fundación Orange. Este informe, que se elabora desde el año 2001, tiene como objetivo describir la realidad de Internet, la Web y los servicios telemáticos en España.
Respecto a la accesibilidad, en este informe podemos encontrar lo siguiente:
Página 113:
Una de las prioridades de la Agenda Digital Europea es el fomento de la accesibilidad a las TIC y los servicios de Internet de las personas con discapacidad. La Acción 64 dentro del pilar VI de la Agenda Digital obliga a que en 2015 sean accesibles según una serie de estándares establecidos por la Comisión Europea bajo el Mandato 376 (disponible a partir de 2014), aquellas páginas web de todos los estados de la Unión Europea que presten servicios relacionados con las declaraciones de impuestos, servicios de empleo, seguridad social, documentos de identidad, gestiones relacionadas con vehículos, permisos de
obra, denuncias, bibliotecas públicas, registro civil, universidades, padrón y servicio nacional de salud. El objetivo se antoja ambicioso en la medida que en la actualidad los cerca de 80 millones de personas con discapacidad y los 87 millones de habitantes mayores de 65 años sólo pueden acceder a un tercio de
los 761.000 portales web de las distintas administraciones públicas que operan en la UE. En España, los niveles de accesibilidad de las páginas web de la Administración General del Estado y de las CC AA son
generalmente altos. De acuerdo a los datos más recientes disponibles del Observatorio de Administración Electrónica, el 80% de los portales de la Administración General del Estado y el 79% de los de las CC AA
cumplían los requisitos de accesibilidad de tipo 1 a fecha de noviembre de 2011.
Los países de mayor tamaño son también los que tienen mayor número de hogares que por discapacidad física o sensorial no pueden acceder a Internet (Gráfico 5.1.15.). Algunos como Hungría tienen un
número anormalmente alto de hogares con personas con discapacidad física o sensorial sin acceso a Internet y por tanto necesitan políticas más intensas de integración digital de este colectivo.
En España, en cerca de 110.000 hogares sus miembros no pueden acceder a Internet por esta razón. Esta cifra supone que en el 8% de los hogares en los que reside una persona con discapacidad física o sensorial, esta discapacidad es la razón por la que el considerado como miembro principal de la vivienda no dispone de acceso a Internet. Hay que tener en cuenta que según los datos del INE de 2008, el tamaño del colectivo de personas con discapacidad con mayor riesgo de exclusión digital, que son las que además viven solas en casa, era de 608.000 individuos en toda España.
En la traslación regional española de este aspecto, es en Galicia, Andalucía y País Vasco donde las personas las personas con discapacidad encuentran mayores problemas para acceder a Internet, mientras que en Madrid, Murcia y Navarra hay menos dificultades (Gráfico 5.1.16.). Las distintas iniciativas de las CC AA
destinadas a desarrollar el uso de las TIC en las personas con discapacidad han sido limitadas y heterogéneas, abarcando desde subvenciones para la compra de productos TIC como en Andalucía hasta cursos de capacitación en Aragón, por ejemplo. Es de esperar que en el futuro la Estrategia Global de Accesibilidad a las Tecnologías de la Información y la Comunicación anunciada por el Ministerio de Sanidad, Servicios Sociales e Igualdad potencie las actividades en este ámbito de una forma coordinada con la Agenda Digital Española y la futura Ley de Discapacidad.
En el informe podemos encontrar más cosas sobre la accesibilidad web. Por ejemplo, se incluye un pequeño análisis de la página principal de los sitios web de los principales partidos políticos.
Respecto a la accesibilidad, en este informe podemos encontrar lo siguiente:
Página 113:
Una de las prioridades de la Agenda Digital Europea es el fomento de la accesibilidad a las TIC y los servicios de Internet de las personas con discapacidad. La Acción 64 dentro del pilar VI de la Agenda Digital obliga a que en 2015 sean accesibles según una serie de estándares establecidos por la Comisión Europea bajo el Mandato 376 (disponible a partir de 2014), aquellas páginas web de todos los estados de la Unión Europea que presten servicios relacionados con las declaraciones de impuestos, servicios de empleo, seguridad social, documentos de identidad, gestiones relacionadas con vehículos, permisos de
obra, denuncias, bibliotecas públicas, registro civil, universidades, padrón y servicio nacional de salud. El objetivo se antoja ambicioso en la medida que en la actualidad los cerca de 80 millones de personas con discapacidad y los 87 millones de habitantes mayores de 65 años sólo pueden acceder a un tercio de
los 761.000 portales web de las distintas administraciones públicas que operan en la UE. En España, los niveles de accesibilidad de las páginas web de la Administración General del Estado y de las CC AA son
generalmente altos. De acuerdo a los datos más recientes disponibles del Observatorio de Administración Electrónica, el 80% de los portales de la Administración General del Estado y el 79% de los de las CC AA
cumplían los requisitos de accesibilidad de tipo 1 a fecha de noviembre de 2011.
Los países de mayor tamaño son también los que tienen mayor número de hogares que por discapacidad física o sensorial no pueden acceder a Internet (Gráfico 5.1.15.). Algunos como Hungría tienen un
número anormalmente alto de hogares con personas con discapacidad física o sensorial sin acceso a Internet y por tanto necesitan políticas más intensas de integración digital de este colectivo.
En España, en cerca de 110.000 hogares sus miembros no pueden acceder a Internet por esta razón. Esta cifra supone que en el 8% de los hogares en los que reside una persona con discapacidad física o sensorial, esta discapacidad es la razón por la que el considerado como miembro principal de la vivienda no dispone de acceso a Internet. Hay que tener en cuenta que según los datos del INE de 2008, el tamaño del colectivo de personas con discapacidad con mayor riesgo de exclusión digital, que son las que además viven solas en casa, era de 608.000 individuos en toda España.
En la traslación regional española de este aspecto, es en Galicia, Andalucía y País Vasco donde las personas las personas con discapacidad encuentran mayores problemas para acceder a Internet, mientras que en Madrid, Murcia y Navarra hay menos dificultades (Gráfico 5.1.16.). Las distintas iniciativas de las CC AA
destinadas a desarrollar el uso de las TIC en las personas con discapacidad han sido limitadas y heterogéneas, abarcando desde subvenciones para la compra de productos TIC como en Andalucía hasta cursos de capacitación en Aragón, por ejemplo. Es de esperar que en el futuro la Estrategia Global de Accesibilidad a las Tecnologías de la Información y la Comunicación anunciada por el Ministerio de Sanidad, Servicios Sociales e Igualdad potencie las actividades en este ámbito de una forma coordinada con la Agenda Digital Española y la futura Ley de Discapacidad.
En el informe podemos encontrar más cosas sobre la accesibilidad web. Por ejemplo, se incluye un pequeño análisis de la página principal de los sitios web de los principales partidos políticos.
jueves, 27 de junio de 2013
¿Será accesible?
Hace unos días se publicó la noticia Los expertos apuestan por crear un super portal en Internet para trámites y servicios. Según la noticia:
Un único portal de Internet centralizará la información de todas las administraciones y permitirá iniciar o realizar los trámites y servicios más relevantes, desde consultar las multas de tráfico, pedir hora para renovar el DNI o consultar las ofertas de empleo público.¿Será accesible? ¿Se acordarán de ello? ¿Qué empresa se embolsará un buen puñado de millones de euros?
Es una de las iniciativas que plantea la Comisión para la Reforma de las Administraciones Públicas (CORA) en su informe, establecer un "auténtico" punto de acceso general como portal de entrada del ciudadano a las administraciones públicas.
La implantación verdadera de la administración electrónica es uno de los ejes centrales del informe de la CORA que, entre otras medidas, propone potenciar la Plataforma de Intermediación de Datos (PID) para hacer efectivo el derecho de los ciudadanos a no tener que presentar documentos que ya obren en poder de la administración.
La creación de un Tablón Edictal Único de todas las administraciones y el establecimiento de un Boletín Oficial del Estado (BOE) "a la carta", con un sistema de alertas que pueda personalizar el ciudadano para consultar toda la normativa en vigor de una determinada materia, es otra de las posibilidades que apunta este informe, que busca acabar con colas, trabas, esperas y dificultades en la relación con la administración.
miércoles, 26 de junio de 2013
La falsa dicotomía entre accesibilidad y usabilidad
¿La usabilidad y la accesibilidad son lo mismo? ¿Una contiene a la otra? ¿Qué relación guardan entre sí? Este tema ya lo he tratado varias veces:
- ¿Accesibilidad vs usabilidad? (18/03/2009)
- Usabilidad, accesibilidad, sentido común (13/03/2013)
- ¿Cómo se puede distinguir la usabilidad de la accesibilidad? (17/5/2013)
Hace poco más de un mes, Ed H. Chi, investigador de Google, estuvo como conferenciante invitado en W4A 2013 con The false dichotomy between accessibility and usability. Algunas ideas de su charla son:
- Si rechazamos la idea de que la accesibilidad y la usabilidad son cosas distintas, nos daremos cuenta de que muchos problemas de accesibilidad son también problemas de usabilidad, y al revés.
- Sin embargo, la creencia en esta dicotomía ha ocasionado la existencia de dos grupos de investigadores que tradicionalmente no hablaban entre sí: los investigadores en HCI (human-computer interaction) y los investigadores en accesibilidad.
- Según Chi, esta separación es artificial y poco beneficiosa para ambas comunidades.
Se ha publicado el vídeo de su charla, pero la calidad no es muy buena:
martes, 25 de junio de 2013
Consejos para mejorar la legibilidad
Cuando explico la accesibilidad web, una duda (a veces, reproche) que plantea mucha gente es que la accesibilidad web sólo beneficia a unos pocos, a las personas con discapacidad. Esta percepción no es cierta, la mayoría de las características que mejoran la accesibilidad web también mejoran la experiencia de uso de otros usuarios siempre o en determinadas situaciones de uso. Y a veces también ocurre al revés: características o consejos destinados para "todos los públicos" tienen un gran impacto en las personas con discapacidad.
Por ejemplo, hace unos días se publicó en el periódico El País el artículo Tuitear sin leer: Nuevo deporte olímpico. Desgraciadamente, la gente cada vez presta menos atención a lo que lee: la mayoría de la gente lee mucho, pero poco de mucho, la mayoría de la gente sólo escanea los artículos, sólo leer las primeras líneas o los primeros párrafos, o incluso, sólo lee el título del artículo y se queda con la idea de que ya sabe de que va el artículo.
En ese artículo se proporcionan unos consejos de Jakob Nielsen para adaptar los artículos a esta situación (los consejos se proporcionan al final, para que sólo aquellos que hayan llegado hasta el final sean afortunados y los disfruten):
Por ejemplo, hace unos días se publicó en el periódico El País el artículo Tuitear sin leer: Nuevo deporte olímpico. Desgraciadamente, la gente cada vez presta menos atención a lo que lee: la mayoría de la gente lee mucho, pero poco de mucho, la mayoría de la gente sólo escanea los artículos, sólo leer las primeras líneas o los primeros párrafos, o incluso, sólo lee el título del artículo y se queda con la idea de que ya sabe de que va el artículo.
En ese artículo se proporcionan unos consejos de Jakob Nielsen para adaptar los artículos a esta situación (los consejos se proporcionan al final, para que sólo aquellos que hayan llegado hasta el final sean afortunados y los disfruten):
- Hacer listas y usar estos puntitos indiscriminadamente.
- Emplear abundancia de negritas y subtítulos para ayudarles con la dispersión.
- Hacer oraciones cortas.
- Plantear una idea por párrafo.
- Prescindir de los juegos de palabras.
- Minimizar las reflexiones profundas sobre cualquier tema porque producen oraciones larguísimas y complicadas como ésta.
- Emplear la mitad de las palabras que se usarían en la escritura convencional.
Excepto el último consejo, que si se abusa de él puede hacer que un texto sea de difícil comprensión o ambiguo, el resto de consejos se emplean también para mejorar la legibilidad de los textos y así mejorar la accesibilidad de cara a las personas con discapacidad.
lunes, 24 de junio de 2013
Conferencia de Victor Tsaran
Ya he hablado de Victor Tsaran en otras ocasiones. Victor trabaja (o trabajaba, nunca se sabe, en Silicon Valley la gente cambia muy a menudo de compañía) en Yahoo! Accessibility Lab.
En el año 2009, Victor realizó una conferencia en TEDx Silicon Valley. En Vimeo podemos encontrar el vídeo de la conferencia: Victor Tsaran: Dis/Ability (el vídeo también está en YouTube, pero el de Vimeo tiene más calidad). Por cierto, no asustarse, la canción termina en el minuto 2:10.
Al principio de la conferencia, Victor comenta que en el mundo hay 650 millones de personas con discapacidad, de los cuales unos 50 millones son ciegos.
Victor también nos cuenta cómo fue su educación, primero en Ucrania y luego en los Estados Unidos. Y una frase importante que pronuncia: "creamos tecnología para mejorar la vida de las personas, pero para las personas con discapacidad no sólo las mejora, sino que en muchos casos permite la vida".
Victor Tsaran: Dis/Ability from TEDx Silicon Valley on Vimeo.
En el año 2009, Victor realizó una conferencia en TEDx Silicon Valley. En Vimeo podemos encontrar el vídeo de la conferencia: Victor Tsaran: Dis/Ability (el vídeo también está en YouTube, pero el de Vimeo tiene más calidad). Por cierto, no asustarse, la canción termina en el minuto 2:10.
Al principio de la conferencia, Victor comenta que en el mundo hay 650 millones de personas con discapacidad, de los cuales unos 50 millones son ciegos.
Victor también nos cuenta cómo fue su educación, primero en Ucrania y luego en los Estados Unidos. Y una frase importante que pronuncia: "creamos tecnología para mejorar la vida de las personas, pero para las personas con discapacidad no sólo las mejora, sino que en muchos casos permite la vida".
Victor Tsaran: Dis/Ability from TEDx Silicon Valley on Vimeo.
domingo, 23 de junio de 2013
La accesibilidad en Estados Unidos es mejor que en España
Hace unos meses comenté que la accesibilidad al medio físico es mejor en Estados Unidos que en España. Hoy se ha publicado el artículo Una Fulbright sin barreras, en el que Inés González, todo un ejemplo de superación, destaca lo mismo:
En Washington, y en Gallaudet en particular, está acostumbrada a que todo sea accesible y a que ella tenga derecho a que lo sea. "Eso no es tan obvio en España. Aquí tienen botones para abrir todas las puertas. Te acostumbras a una calidad de vida y a una independencia física que será difícil en España", cuenta González, que las pasadas Navidades estuvo en Colombia y cuenta que casi no pudo salir del coche.
Además, en el artículo Inés explica algo que mucha gente desconoce: la lengua de signos es distinta de un país a otro, incluso entre países que comparten la misma lengua oral, como los hispanoamericanos.
sábado, 22 de junio de 2013
Noticia sobre mi análisis de Renfe
Ayer se publicó el artículo La Universidad de Alicante realiza un estudio sobre la accesibilidad web de Renfe en el que se comenta mi análisis sobre la accesibilidad de la nueva web de Renfe.
viernes, 21 de junio de 2013
Conoce a Victor Tsaran
Victor Tsaran trabaja (o trabajaba) en Yahoo! Accessibility Lab. En el vídeo Meet Victor Tsaran of Yahoo! Accessibility, Victor explica algunas cosas de su trabajo y comenta el importante impacto que tienen las tecnologías en las personas con discapacidad. El vídeo tiene subtítulos en inglés:
jueves, 20 de junio de 2013
Cómo hacer que una imagen compleja sea accesible
Pues muy sencillo: proporcionando la información que contiene mediante una alternativa que sea accesible, como por ejemplo, con texto.
Dos ejemplos reales:
Dos ejemplos reales:
miércoles, 19 de junio de 2013
Eficiencia y ahorro con la aplicación de tecnologías accesibles en las Administraciones Públicas
Hace unas semanas, el Centro Nacional de Tecnologías de la Accesibilidad (CENTAC) presentó el informe Eficiencia y Ahorro con la aplicación de Tecnologías Accesibles en las Administraciones Públicas. Este informe, de 143 páginas, se puede descargar de forma gratuita.
El resumen del informe dice:
En fin, el típico informe que se podría haber resumido en 10 páginas.
El resumen del informe dice:
El objetivo este volumen es mostrar a las Administraciones Públicas que la inversión en tecnologías accesibles no es una inversión a fondo perdido, sino que permite recuperar el capital invertido y, además, obtener importantes beneficios gracias al ahorro de costes que se produce con la implantación de este tipo de tecnologías.Cuando avisé de la presentación de este informe, ya dije que tenía mucho interés en consultarlo "porque una cosa es decir que la accesibilidad no cuesta mucho y otra es decir que incluso permite el ahorro". El misterio está resuelto: en el informe se mezclan diferentes contextos de uso de nuevas tecnologías en diferentes contextos (medicina, educación, empleo) que en algunos casos sí que se pueden considerar "tecnologías accesibles", pero que en otros muchos casos son simplemente nuevas tecnologías de uso general. Incluso aparecen las famosas "ciudades inteligentes" que tan de moda están últimamente.
Se han analizado los principales sectores productivos que gestionan las instituciones públicas, tanto ámbitos verticales o sectores específicos: Sanidad, Educación y Empleo; como ámbitos horizontales o sectores transversales, es el caso de la Administración Electrónica o las Ciudades Inteligentes (Smart Cities). Este análisis se complementa con diversos casos específicos, en los que se detalla cuantitativamente cómo la implantación de las tecnologías accesibles impacta de forma positiva en los procesos de gestión y cómo se reducen significativamente los costes que actualmente están soportando las instituciones públicas.
Además el informe incorpora un análisis socio-económico del impacto de las compras TIC potencialmente accesibles en la economía nacional, y un análisis estratégico DAFO, previo a las conclusiones finales del volumen.
En fin, el típico informe que se podría haber resumido en 10 páginas.
martes, 18 de junio de 2013
Diseño adaptable y accesibilidad
Hace unas semanas publiqué una entrada sobre cómo desactivar el diseño web adaptable, ya que puede causar problemas de uso entre algunos usuarios. Por tanto, puede suponer un problema de accesibilidad.
En Responsive Web Design and Accessibility, varios expertos discuten sobre cómo encajan el diseño web adaptable y la accesibilidad. Algunas de las frases que se destacan en esta discusión:
Both responsive Web design and accessibility are ways of making a site flexible.
Responsive Web design and accessibility are very complementary, but … doing responsive design does notmean that you automatically have an accessible site or application and vice versa.
Responsive design and accessibility are orthogonal. You can have accessible sites that aren’t responsive. You can have responsive sites that aren’t accessible.
As responsible Web designers, we should be building Web sites in such a way that people using accessibility technologies are able to have a coherent user experience.
Creating Web sites that work with different devices is … a good start for accessibility.
Both responsive Web design and accessibility rely on coding a site to standards. “This includes separating the content from the display rules.
lunes, 17 de junio de 2013
ChromeVox puede revolucionar los lectores de pantalla
A través del artículo Screen Readers at a Crossroads he podido ver la presentación que se hizo sobre ChromeVox en el reciente Google I/O: Google I/O 2013 - Advancing Web Accessibility with ChromeVox.
Por si no lo sabes, ChromeVox es un complemento del navegador Google Chrome que integra un lector de pantallas en el propio navegador.
Google ha creado un API para ChromeVox, de forma que desde una página web se puede proporcionar información adicional a ChromeVox para que éste interprete y lea las páginas web tal como el creador de la página web quiera. Esto ofrece un abanico nuevo de posibilidades, pero también abre la puerta a muchos abusos que pueden producir una fragmentación de la accesibilidad.
Lo más interesante que se muestra en el vídeo es la utilización de esta API para la interpretación de contenido matemático en formato MathML. ¡Todo un avance muy interesante!
Por si no lo sabes, ChromeVox es un complemento del navegador Google Chrome que integra un lector de pantallas en el propio navegador.
Google ha creado un API para ChromeVox, de forma que desde una página web se puede proporcionar información adicional a ChromeVox para que éste interprete y lea las páginas web tal como el creador de la página web quiera. Esto ofrece un abanico nuevo de posibilidades, pero también abre la puerta a muchos abusos que pueden producir una fragmentación de la accesibilidad.
Lo más interesante que se muestra en el vídeo es la utilización de esta API para la interpretación de contenido matemático en formato MathML. ¡Todo un avance muy interesante!
viernes, 14 de junio de 2013
Generador de declaraciones de accesibilidad
En el artículo Nomensa launches accessibility declaration tool nos explican de qué va esto, y en Accessibility Statement Generator lo podemos encontrar.
Es un un asistente online que ayuda a generar declaraciones de accesibilidad web. Desgraciadamente, sólo está disponible en inglés.
Es un un asistente online que ayuda a generar declaraciones de accesibilidad web. Desgraciadamente, sólo está disponible en inglés.
jueves, 13 de junio de 2013
Reproductor de vídeo accesible
En YouTube Flash player with captions, presentan un reproductor de vídeo accesible, basado en Flash, que proporciona controles accesibles para personas que utilizan un lector de pantalla o que manejan el ordenador con el teclado.
miércoles, 12 de junio de 2013
Taller de expertos "Herramientas TIC y contenidos accesibles en educación"
El CENTAC, el Centro Nacional de Tecnologías de la Accesibilidad, organiza este jueves 13 de junio de 2013 el taller Herramientas TIC y contenidos accesibles en educación, que se podrá seguir en directo mediante streaming a través de Internet.
La nota de prensa indica:
La nota de prensa indica:
La educación es sin duda uno de los temas candentes de la actualidad, en los medios se refleja el continuo debate sobre la formación libre y para todos. No obstante, desde CENTAC creemos que en ese "para todos" es imprescindible incluir a las personas con discapacidad, y las TIC son una oportunidad para lograrlo.
Además, en las conclusiones de varios de nuestros talleres hemos recogido que la educación es un vehículo fundamental para la normalización de la discapacidad, sin embargo la realidad indica que todavía queda mucho camino por recorrer. Las TIC están transformando el mundo educativo porque ofrecen enormes posibilidades para encontrar nuevos canales, nuevas formas de enseñar y nuevas formas de aprender. Pero, ¿que ocurre si no son accesibles? ¿Ayudan o suponen un freno?
Estas son algunas de las posibles preguntas sobre las que hablaremos en nuestro próximo taller del 13 de junio, donde expertos que están en el día a día trabajando con alumnos con discapacidad nos hablarán de las posibilidades y realidades que hoy en día están ofreciendo las TIC en la educación y cómo las están incorporando en sus métodos de enseñanza, también hablaremos sobre cómo están haciendo que los contenidos sean accesibles para sus alumnos con discapacidad.
Los diez problemas más comunes
En el artículo Ten Common Accessibility Problems, su autor recopila los diez problemas más comunes en base a su experiencia como revisor de la accesibilidad de numerosos sitios web. En esta lista, el orden de los problemas no es significativo:
- No incluir el texto alternativo para las imágenes.
- Uso de CAPTCHA.
- No proporcionar alternativas adecuadas para contenido inaccesible.
- No usar los encabezados de HTML de forma apropiada.
- No asociar de forma explícita los controles de un formulario con sus etiquetas.
- No garantizar la suficiente diferencia de contraste entre el color del texto y el color de fondo.
- No identificar las tablas de datos con summary o caption.
- No etiquetar las tablas de datos correctamente.
- No garantizar que las páginas se pueden usar sin el ratón.
- Uso del evento onchange en los menús de tipo select.
Si quieres más consejos similares, en Consejos para crear páginas web accesibles recopilo varias listas de este tipo.
martes, 11 de junio de 2013
Adif, errores solucionados
Hace dos meses publiqué el vídeo Errores Web: Renfe, Adif y los nombres de las estaciones:
En el vídeo mostraba un problema que no es realmente un problema de accesibilidad, afecta a todos los usuarios: las provincias de Álava y León aparecían repetidas. Pero problemas como el de los nombres de las estaciones se pueden ver potenciados de forma negativa en el caso de las personas con discapacidad.
Por ejemplo, en la lista de provincias aparecían repetidas las provincias de Álava y León, y las estaciones de ambas provincias se repartían entre las dos repeticiones. Una persona que ve tiene más fácil darse cuenta de que esas provincias aparecen repetidas que una persona ciega que usa un lector de pantallas.
Desde aquí, le doy las gracias a Adif por resolver este problema, que no sé si lo han hecho a raíz de mi vídeo, pero resuelto está.
En la siguiente imagen vemos que la provincia de Álava ya no aparece repetida, además, también han corregido el nombre de Vizcaya:
En la siguiente imagen vemos que la provincia de León tampoco aparece repetida:
Ahora ya sólo falta que Renfe resuelva el lío que tiene con el nombre de las estaciones.
En el vídeo mostraba un problema que no es realmente un problema de accesibilidad, afecta a todos los usuarios: las provincias de Álava y León aparecían repetidas. Pero problemas como el de los nombres de las estaciones se pueden ver potenciados de forma negativa en el caso de las personas con discapacidad.
Por ejemplo, en la lista de provincias aparecían repetidas las provincias de Álava y León, y las estaciones de ambas provincias se repartían entre las dos repeticiones. Una persona que ve tiene más fácil darse cuenta de que esas provincias aparecen repetidas que una persona ciega que usa un lector de pantallas.
Desde aquí, le doy las gracias a Adif por resolver este problema, que no sé si lo han hecho a raíz de mi vídeo, pero resuelto está.
En la siguiente imagen vemos que la provincia de Álava ya no aparece repetida, además, también han corregido el nombre de Vizcaya:
En la siguiente imagen vemos que la provincia de León tampoco aparece repetida:
Ahora ya sólo falta que Renfe resuelva el lío que tiene con el nombre de las estaciones.
lunes, 10 de junio de 2013
Semana de puertas abiertas del CEAPAT
El Centro de Referencia Estatal de Autonomía Personal y Ayudas Técnicas, CEAPAT, centro
perteneciente al IMSERSO, celebra su semana de puertas abiertas del 10 al 14 de junio, donde usuarios,
técnicos y empresas comparten experiencias sobre nuevas tecnologías y accesibilidad.
Entre otras actividades, se han organizado unas jornadas técnicas que se retransmiten en directo vía streaming por la empresa EDSOL PRODUCCIONES, especializada en la retransmisión de eventos en directo a través de Internet.
Según la nota de prensa del evento:
http://www.ceapat.es/ceapat_01/el_ceapat/ceapat_directo/retransmision/index.htm
http://www.edsolproducciones.com/ceapat.html
Entre otras actividades, se han organizado unas jornadas técnicas que se retransmiten en directo vía streaming por la empresa EDSOL PRODUCCIONES, especializada en la retransmisión de eventos en directo a través de Internet.
Según la nota de prensa del evento:
La retransmisión de las jornadas incluye el subtitulado e la interpretación en lengua de signos en directo que pueden activarse o desactivarse a voluntad del usuario. Además de incluirse incrustados en el vídeo, los subtítulos están disponibles en modo texto. Esto permite su seguimiento por línea Braille para personas ciegas y sordociegas. Otra ventaja de este tipo de subtitulado es que al finalizar el evento se dispone de todo el texto para su consulta y edición por parte de periodistas y bloggers.Las jornadas se pueden seguir a través de cualquiera de estos dos enlaces:
http://www.ceapat.es/ceapat_01/el_ceapat/ceapat_directo/retransmision/index.htm
http://www.edsolproducciones.com/ceapat.html
De WCAG 1.0 a WCAG 2.0
Migrating from WCAG 1.0 to WCAG 2.0 (Incorporating W3C WCAG 2.0 Recommendation) es un documento que preparó Roger Hudson para ayudar a realizar la transición de WCAG 1.0 a 2.0. En este documento se establece la correspondencia entre los puntos de verificación de WCAG 1.0 y los criterios de éxito de WCAG 2.0.
INTECO publicó un documento parecido llamado Hacia las Pautas WCAG 2.0 hace tiempo.
INTECO publicó un documento parecido llamado Hacia las Pautas WCAG 2.0 hace tiempo.
sábado, 8 de junio de 2013
Vuelve el atributo longdesc a Firefox
Hace unos meses avisé que el atributo longdesc volvía a HTML5, aunque no de forma directa, sino a través de una extensión.
Ahora, uno de los miembros del equipo de desarrollo de Firefox ha publicado otro anuncio muy bueno: After further looking into this, we've decided to support the longdesc attribute in Firefox.
El anuncio completo dice:
Ahora, uno de los miembros del equipo de desarrollo de Firefox ha publicado otro anuncio muy bueno: After further looking into this, we've decided to support the longdesc attribute in Firefox.
El anuncio completo dice:
After further looking into this, we've decided to support the longdesc attribute in Firefox.Y justo hace unos días, el 6 de junio, se publicó una nueva versión de HTML5 Image Description Extension. Poco a poco se acerca más al "last call" para por fin llegar al nivel de "recommendation".
While we've considered longdesc in the past, the landscape has changed and there are reasons to support it now. For one, the W3C validator now supports it, making it more likely to be supported across browsers. Authors who want to make pages accessible may not be able to rely on longdesc on any browser, but there isn't presently another standardized option available. And, importantly, it can be implemented without disrupting the user experience of users who don't require it. Underscoring all of this is that the Mozilla project is a community, and our actions must reflect the needs and wants of the community.
There is a chicken and egg issue here, as Alastair notes in comment 20. Supporting longdesc means that the door to wider adoption is open, and perhaps authors will surprise us with innovative uses of this attribute once they feel freer to do so. And, perhaps in time better solutions to some of the problems longdesc tackles will emerge. While we'll always be open to browser improvements, particularly in the accessibility space, we shouldn't ignore a ready solution because it's not perfect.
viernes, 7 de junio de 2013
La accesibilidad de la web de Renfe (2)
Ayer publiqué la primera parte del vídeo sobre la accesibilidad de la nueva web de Renfe, y hoy publico la segunda parte del vídeo. En este vídeo se muestran los principales problemas de accesibilidad que presentan dos páginas, la página principal del sitio web y la página que aparece cuando se introducen los datos de un viaje y se pulsa en el botón "Comprar":
Y la transcripción del audio:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo vamos a ver algunos problemas graves de accesibilidad que presenta el nuevo sitio web de Renfe.
Este vídeo consta de varias partes y ha sido realizado con la colaboración de Ramón Corominas y Jesús Álvarez del Amo, que realizaron una presentación sobre los problemas de la web de Renfe en el marco de las reuniones de “Madrid Accesibilidad TICs”.
En el vídeo anterior, vimos que en los últimos meses ha habido varias quejas de usuarios respecto a los problemas de usabilidad y de accesibilidad de la nueva web de Renfe. En este vídeo vamos a ver los principales problemas de accesibilidad.
En concreto, vamos a ver los problemas que presentan dos páginas, la página principal y la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
Voy a empezar con la validación del código HTML de la página principal, ya que las dos versiones de las Pautas de Accesibilidad al Contenido en la Web del W3C lo exigen.
Los resultados que se obtienen con el validador oficial del W3C son desastrosos, 75 errores y 7 advertencias.
Vamos a ver los primeros errores simplemente para tener una idea de su naturaleza.
La página tiene definido el DOCTYPE XHTML 1.0 Strict, lo cual está muy bien.
El primer error es que la página contiene el atributo “onLoad” con la “l” en mayúsculas. En XHTML los atributos se tienen que escribir todos en minúsculas.
A continuación, hay errores en el primer formulario, porque está escrito directamente dentro de la etiqueta form, y eso no es posible. Los campos de un formulario deben de escribirse dentro de un elemento de bloque, como un párrafo p o un contenedor div.
Este formulario tiene campos de tipo input que no han sido cerrados. Sin embargo, es gracioso ver que otras etiquetas de tipo input sí que han sido cerradas correctamente. ¿A qué se debe este error? ¿A un olvido? ¿A las prisas? ¿A una falta de control de calidad?
Y bueno, así hasta llegar a los 75 errores.
La herramienta de evaluación de la accesibilidad WAVE detecta 5 errores y 22 advertencias.
Los cinco errores son campos del formulario que no tienen asociados una etiqueta label que los identifique.
En realidad, como podemos ver, sí que existen las etiquetas label para esos campos, pero la asociación está mal hecha, porque el valor del atributo “for” no se corresponde con el atributo “id” o el campo no tiene atributo “id”.
Por cierto, en este fragmento de código sorprende encontrarse dos etiquetas input escritas en mayúsculas. Eso es otro error de validación.
En 10 ocasiones, el atributo “title” usado en enlaces es redundante, porque repite el mismo texto que contiene el enlace. Eso es totalmente inútil, no sirve para nada, pero puede ocasionar problemas.
WAVE señala como una advertencia, como un posible error el uso de “accesskey”, los atajos de teclado, nueve veces. Aunque en principio es una característica destinada a mejorar la accesibilidad, normalmente se desaconseja su uso, ya que estos atajos de teclado pueden interferir con los atajos de teclado que tenga definido el usuario. Por lo tanto, es mejor no usarlo en un sitio web destinado a todo el público.
La herramienta de evaluación TAW detecta 13 errores automáticos de prioridad 2.
Los errores detectados son básicamente los mismos que hemos visto antes: los campos de los formularios están mal etiquetados.
La herramienta de evaluación eXaminator proporciona una nota de 6,5 sobre 10. En la página web de Renfe hay 6 pruebas que se valoran como “mal”.
eXaminator detecta un error importante: hay un formulario sin un botón de envío.
Efectivamente, el formulario principal, el de compra de billetes, el que seguramente más le interesa a los usuarios, y más le tiene que interesar a Renfe porque es su fuente de ingresos, no tiene botón de envío.
Estos dos botones que vemos aquí, “Todas las estaciones” y “Comprar”, no son realmente botones, visualmente parecen botones, pero son enlaces que realizan la función de botones.
Aunque no es una barrera de accesibilidad grave, sí que puede causar confusión entre algunos usuarios.
Además, eXaminator también detecta que hay un valor del atributo id repetido en la página.
Este error está otra vez relacionado con los campos de los formularios.
En definitiva, que la página web contiene numerosos errores. Alguien puede decir que no son errores importantes, pero aunque fuese verdad, que no lo es, son un claro síntoma del poco cuidado que tiene la gente que desarrolla el sitio web de Renfe.
Antes de continuar, hay que recordar que las herramientas automáticas de evaluación de la accesibilidad no son capaces de detectar todos los problemas. En realidad, los problemas más graves que presenta la página web de Renfe, que los vamos a ver a continuación, no son detectados por las herramientas que acabamos de ver.
Como ya podemos intuir por los resultados de las herramientas automáticas de evaluación de la accesibilidad, los problemas más graves están en el formulario de compra.
En este formulario, el origen y el destino de un viaje sí que están correctamente identificados por una etiqueta label.
Pero la fecha de salida y la fecha de regreso no están correctamente relacionadas con sus correspondientes etiquetas.
Por cierto, en este fragmento de código, ¿qué hace un div dentro de un párrafo? Eso es otro error de validación.
Sin la correcta identificación de los campos, un usuario ciego que utiliza un lector de pantallas, no sabe qué tiene que introducir en estos dos campos.
Además, ¿qué formato de fecha se debe emplear? Este ya no es sólo un problema de accesibilidad, sino que es un problema de usabilidad porque afecta a todos los usuarios.
Y ya que estamos, otro problema de usabilidad. Si aquí se habla de “Ida y vuelta”, ¿por qué no emplea la misma denominación aquí? ¿Por qué se emplea “Salida” y “Regreso”?
En realidad, podemos ver que en esta versión del sitio web de Renfe de abril de 2010, se empleaban los términos “Ida” y “Vuelta” para la fecha de ida y la fecha de vuelta.
Pero el problema más grave es la lista de búsqueda de estaciones para el origen y el destino.
La lista desplegable que aparece se puede emplear con el teclado sin problemas, pero no es accesible para los usuarios ciegos que utilizan un lector de pantallas, pero este problema se explicará en un siguiente vídeo.
Un aspecto positivo que tiene la página principal de Renfe es el empleo correcto de los encabezados. Sin embargo, vamos a ver que no ocurre lo mismo en todas las páginas.
Estos son todos los encabezados que hay en la página principal de Renfe.
Se podría haber hecho un poco mejor, ya que hay una zona muy importante que no tiene encabezados, el apartado de redes sociales.
Justo en el apartado de redes sociales encontramos un problema importante: no avisa de que los enlaces se abren en una ventana nueva.
En realidad, abrir un enlace en una ventana nueva es una mala opción para todos los usuarios, el usuario tiene que tener la libertad de tomar la decisión de abrir un enlace en una ventana nueva, no se debe decidir por el usuario.
Y otra pregunta, ¿por qué dos listas? Se podría haber hecho con una sola lista y habría sido más significativo.
Pero curiosamente, esta barra de navegación, cuyos enlaces también se abren en una ventana nueva, como podemos ver en este fragmento de código, sí que tienen un aviso, en concreto “Se abre en ventana nueva”, que añade un pequeño icono con ese texto alternativo a los enlaces anteriores que tienen un id con el valor “opc” más un número.
¿Y el “BonoAVE”, por qué no tiene la imagen y el aviso? Muy sencillo, porque se les olvidó poner atributo id en el enlace de “BonoAVE”.
Bien, ahora vamos a ver la segunda página, la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
En esta página el usuario tiene que elegir el tren que desea utilizar entre todos los que ha encontrado Renfe que cumplen sus criterios de búsqueda.
En esta página hay un error tremendo.
Mientras que en la página anterior, la página principal, los encabezados estaban correctamente etiquetados, en esta página los encabezados son un desastre y no sirven para nada.
¿Dónde está el problema? El problema está en que no se han cerrado correctamente los encabezados.
Por ejemplo, aquí tenemos el primer encabezado h1 que sí que está cerrado correctamente.
Pero el segundo encabezado h1 no se cierra correctamente, e incluye todo lo que viene a continuación.
Este encabezado se abre en la línea 511, y se cierra posteriormente en la línea 597.
Pero como podemos ver aquí, esto no sólo ocurre con este encabezado, ocurre lo mismo con los siguientes encabezados de la página.
Otro problema importante se encuentra en este panel para cambiar el día del viaje.
En primer lugar, hay un problema de usabilidad importante. El color gris se suele emplear para indicar que un elemento de interacción como un botón, no es utilizable, sin embargo, en esta página, estos dos botones que aparecen en gris sí que se pueden utilizar.
Pero el problema de accesibilidad lo detectamos al ver el código fuente. Otra vez, lo que aparentemente son botones, en realidad no son botones.
Son enlaces a los que se les ha asignado una acción con el evento “onclick”.
Si algo parece un botón y actúa como un botón, ¿por qué no está etiquetado como un botón?
Pero además, el texto de estos enlaces no es significativo, no identifica correctamente la función del enlace, del botón. ¿”Día antes” y “Después”, de qué?
Algunos usuarios, por ejemplo los usuarios ciegos que utilizan un lector de pantallas, navegan por las páginas web a través de una lista que contiene todos los enlaces de la página.
En la página de Renfe, a los usuarios ciegos les aparece repetido el enlace “Día Antes” y “Después”, pero no saben si se refiere al viaje de ida o de vuelta.
Por cierto, en la página principal se usan los términos “Salida” y “Regreso”, ¿por qué se emplean ahora los términos “Ida” y “Vuelta”? ¿No crea un poco de confusión?
Y ya para finalizar, dos botones más que no son realmente botones.
Por un lado, el botón “Entrar”, del formulario para acceder como un usuario registrado no es realmente un botón, es, otra vez, un enlace que hace creer que es un botón.
Por otro lado, al final de la página aparece el botón “Continuar”, que tampoco es realmente un botón, sino que es un enlace con una acción asociada.
Y además, qué codigo HTML más raro: un h3, que tiene dentro un div, que a su vez tiene un enlace a, que a su vez tiene otro div.
En resumen, sin duda alguna, de la nueva página web de Renfe se puede decir que se puede hacer mal, pero peor que esto, imposible.
Y con esto finaliza este videotutorial que ha mostrado algunos de los problemas de accesibilidad que presenta el sitio web de Renfe.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
- En la página principal:
- Errores de validación del código HTML.
- Hay campos en el formulario de selección de trenes que no tienen una etiqueta que los identifique.
- Atributo title en enlaces redundante porque repite la misma información que contiene el enlace.
- El formulario de selección de trenes no tiene un botón de envío, es un enlace.
- No se indica el formato para introducir la fecha de salida y de regreso.
- La lista de estaciones no es accesible para los usuarios ciegos.
- Ausencia de encabezados en algunas zonas importantes.
- No se avisa de que ciertos enlaces se abren en una ventana nueva (en realidad, no se debería abrir ninguno en una ventana nueva).
- Y en la segunda página, la que sale una vez se han completado el formulario de compra:
- Errores de validación del código HTML, como una tabla con dos títulos, que pueden repercutir en la accesibilidad.
- Los encabezados son un verdadero desastre.
- Los botones para pasar al día anterior o al día siguiente no son botones, son enlaces.
- El formulario para acceder como un usuario registrado no tiene un botón de envío, es un enlace.
- El botón para continuar con la compra no es un botón, es un enlace.
Y la transcripción del audio:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y en este vídeo vamos a ver algunos problemas graves de accesibilidad que presenta el nuevo sitio web de Renfe.
Este vídeo consta de varias partes y ha sido realizado con la colaboración de Ramón Corominas y Jesús Álvarez del Amo, que realizaron una presentación sobre los problemas de la web de Renfe en el marco de las reuniones de “Madrid Accesibilidad TICs”.
En el vídeo anterior, vimos que en los últimos meses ha habido varias quejas de usuarios respecto a los problemas de usabilidad y de accesibilidad de la nueva web de Renfe. En este vídeo vamos a ver los principales problemas de accesibilidad.
En concreto, vamos a ver los problemas que presentan dos páginas, la página principal y la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
Voy a empezar con la validación del código HTML de la página principal, ya que las dos versiones de las Pautas de Accesibilidad al Contenido en la Web del W3C lo exigen.
Los resultados que se obtienen con el validador oficial del W3C son desastrosos, 75 errores y 7 advertencias.
Vamos a ver los primeros errores simplemente para tener una idea de su naturaleza.
La página tiene definido el DOCTYPE XHTML 1.0 Strict, lo cual está muy bien.
El primer error es que la página contiene el atributo “onLoad” con la “l” en mayúsculas. En XHTML los atributos se tienen que escribir todos en minúsculas.
A continuación, hay errores en el primer formulario, porque está escrito directamente dentro de la etiqueta form, y eso no es posible. Los campos de un formulario deben de escribirse dentro de un elemento de bloque, como un párrafo p o un contenedor div.
Este formulario tiene campos de tipo input que no han sido cerrados. Sin embargo, es gracioso ver que otras etiquetas de tipo input sí que han sido cerradas correctamente. ¿A qué se debe este error? ¿A un olvido? ¿A las prisas? ¿A una falta de control de calidad?
Y bueno, así hasta llegar a los 75 errores.
La herramienta de evaluación de la accesibilidad WAVE detecta 5 errores y 22 advertencias.
Los cinco errores son campos del formulario que no tienen asociados una etiqueta label que los identifique.
En realidad, como podemos ver, sí que existen las etiquetas label para esos campos, pero la asociación está mal hecha, porque el valor del atributo “for” no se corresponde con el atributo “id” o el campo no tiene atributo “id”.
Por cierto, en este fragmento de código sorprende encontrarse dos etiquetas input escritas en mayúsculas. Eso es otro error de validación.
En 10 ocasiones, el atributo “title” usado en enlaces es redundante, porque repite el mismo texto que contiene el enlace. Eso es totalmente inútil, no sirve para nada, pero puede ocasionar problemas.
WAVE señala como una advertencia, como un posible error el uso de “accesskey”, los atajos de teclado, nueve veces. Aunque en principio es una característica destinada a mejorar la accesibilidad, normalmente se desaconseja su uso, ya que estos atajos de teclado pueden interferir con los atajos de teclado que tenga definido el usuario. Por lo tanto, es mejor no usarlo en un sitio web destinado a todo el público.
La herramienta de evaluación TAW detecta 13 errores automáticos de prioridad 2.
Los errores detectados son básicamente los mismos que hemos visto antes: los campos de los formularios están mal etiquetados.
La herramienta de evaluación eXaminator proporciona una nota de 6,5 sobre 10. En la página web de Renfe hay 6 pruebas que se valoran como “mal”.
eXaminator detecta un error importante: hay un formulario sin un botón de envío.
Efectivamente, el formulario principal, el de compra de billetes, el que seguramente más le interesa a los usuarios, y más le tiene que interesar a Renfe porque es su fuente de ingresos, no tiene botón de envío.
Estos dos botones que vemos aquí, “Todas las estaciones” y “Comprar”, no son realmente botones, visualmente parecen botones, pero son enlaces que realizan la función de botones.
Aunque no es una barrera de accesibilidad grave, sí que puede causar confusión entre algunos usuarios.
Además, eXaminator también detecta que hay un valor del atributo id repetido en la página.
Este error está otra vez relacionado con los campos de los formularios.
En definitiva, que la página web contiene numerosos errores. Alguien puede decir que no son errores importantes, pero aunque fuese verdad, que no lo es, son un claro síntoma del poco cuidado que tiene la gente que desarrolla el sitio web de Renfe.
Antes de continuar, hay que recordar que las herramientas automáticas de evaluación de la accesibilidad no son capaces de detectar todos los problemas. En realidad, los problemas más graves que presenta la página web de Renfe, que los vamos a ver a continuación, no son detectados por las herramientas que acabamos de ver.
Como ya podemos intuir por los resultados de las herramientas automáticas de evaluación de la accesibilidad, los problemas más graves están en el formulario de compra.
En este formulario, el origen y el destino de un viaje sí que están correctamente identificados por una etiqueta label.
Pero la fecha de salida y la fecha de regreso no están correctamente relacionadas con sus correspondientes etiquetas.
Por cierto, en este fragmento de código, ¿qué hace un div dentro de un párrafo? Eso es otro error de validación.
Sin la correcta identificación de los campos, un usuario ciego que utiliza un lector de pantallas, no sabe qué tiene que introducir en estos dos campos.
Además, ¿qué formato de fecha se debe emplear? Este ya no es sólo un problema de accesibilidad, sino que es un problema de usabilidad porque afecta a todos los usuarios.
Y ya que estamos, otro problema de usabilidad. Si aquí se habla de “Ida y vuelta”, ¿por qué no emplea la misma denominación aquí? ¿Por qué se emplea “Salida” y “Regreso”?
En realidad, podemos ver que en esta versión del sitio web de Renfe de abril de 2010, se empleaban los términos “Ida” y “Vuelta” para la fecha de ida y la fecha de vuelta.
Pero el problema más grave es la lista de búsqueda de estaciones para el origen y el destino.
La lista desplegable que aparece se puede emplear con el teclado sin problemas, pero no es accesible para los usuarios ciegos que utilizan un lector de pantallas, pero este problema se explicará en un siguiente vídeo.
Un aspecto positivo que tiene la página principal de Renfe es el empleo correcto de los encabezados. Sin embargo, vamos a ver que no ocurre lo mismo en todas las páginas.
Estos son todos los encabezados que hay en la página principal de Renfe.
Se podría haber hecho un poco mejor, ya que hay una zona muy importante que no tiene encabezados, el apartado de redes sociales.
Justo en el apartado de redes sociales encontramos un problema importante: no avisa de que los enlaces se abren en una ventana nueva.
En realidad, abrir un enlace en una ventana nueva es una mala opción para todos los usuarios, el usuario tiene que tener la libertad de tomar la decisión de abrir un enlace en una ventana nueva, no se debe decidir por el usuario.
Y otra pregunta, ¿por qué dos listas? Se podría haber hecho con una sola lista y habría sido más significativo.
Pero curiosamente, esta barra de navegación, cuyos enlaces también se abren en una ventana nueva, como podemos ver en este fragmento de código, sí que tienen un aviso, en concreto “Se abre en ventana nueva”, que añade un pequeño icono con ese texto alternativo a los enlaces anteriores que tienen un id con el valor “opc” más un número.
¿Y el “BonoAVE”, por qué no tiene la imagen y el aviso? Muy sencillo, porque se les olvidó poner atributo id en el enlace de “BonoAVE”.
Bien, ahora vamos a ver la segunda página, la página que aparece al introducir los datos de un viaje y pulsar en el botón comprar.
En esta página el usuario tiene que elegir el tren que desea utilizar entre todos los que ha encontrado Renfe que cumplen sus criterios de búsqueda.
En esta página hay un error tremendo.
Mientras que en la página anterior, la página principal, los encabezados estaban correctamente etiquetados, en esta página los encabezados son un desastre y no sirven para nada.
¿Dónde está el problema? El problema está en que no se han cerrado correctamente los encabezados.
Por ejemplo, aquí tenemos el primer encabezado h1 que sí que está cerrado correctamente.
Pero el segundo encabezado h1 no se cierra correctamente, e incluye todo lo que viene a continuación.
Este encabezado se abre en la línea 511, y se cierra posteriormente en la línea 597.
Pero como podemos ver aquí, esto no sólo ocurre con este encabezado, ocurre lo mismo con los siguientes encabezados de la página.
Otro problema importante se encuentra en este panel para cambiar el día del viaje.
En primer lugar, hay un problema de usabilidad importante. El color gris se suele emplear para indicar que un elemento de interacción como un botón, no es utilizable, sin embargo, en esta página, estos dos botones que aparecen en gris sí que se pueden utilizar.
Pero el problema de accesibilidad lo detectamos al ver el código fuente. Otra vez, lo que aparentemente son botones, en realidad no son botones.
Son enlaces a los que se les ha asignado una acción con el evento “onclick”.
Si algo parece un botón y actúa como un botón, ¿por qué no está etiquetado como un botón?
Pero además, el texto de estos enlaces no es significativo, no identifica correctamente la función del enlace, del botón. ¿”Día antes” y “Después”, de qué?
Algunos usuarios, por ejemplo los usuarios ciegos que utilizan un lector de pantallas, navegan por las páginas web a través de una lista que contiene todos los enlaces de la página.
En la página de Renfe, a los usuarios ciegos les aparece repetido el enlace “Día Antes” y “Después”, pero no saben si se refiere al viaje de ida o de vuelta.
Por cierto, en la página principal se usan los términos “Salida” y “Regreso”, ¿por qué se emplean ahora los términos “Ida” y “Vuelta”? ¿No crea un poco de confusión?
Y ya para finalizar, dos botones más que no son realmente botones.
Por un lado, el botón “Entrar”, del formulario para acceder como un usuario registrado no es realmente un botón, es, otra vez, un enlace que hace creer que es un botón.
Por otro lado, al final de la página aparece el botón “Continuar”, que tampoco es realmente un botón, sino que es un enlace con una acción asociada.
Y además, qué codigo HTML más raro: un h3, que tiene dentro un div, que a su vez tiene un enlace a, que a su vez tiene otro div.
En resumen, sin duda alguna, de la nueva página web de Renfe se puede decir que se puede hacer mal, pero peor que esto, imposible.
Y con esto finaliza este videotutorial que ha mostrado algunos de los problemas de accesibilidad que presenta el sitio web de Renfe.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
jueves, 6 de junio de 2013
La accesibilidad de la web de Renfe (1)
El pasado 8 de febrero de 2013, Renfe cambió sus tarifas y aprovechó el cambio para introducir algunos cambios en su web.
Desgraciadamente, los cambios hicieron que los problemas de accesibilidad aumentaran, y ahora mismo una persona ciega que utilice un lector de pantallas no puede comprar un billete de tren ella sola.
José Ángel Carrey, un usuario ciego, se puso en contacto con Renfe para comunicar el problema, lo denuncio públicamente y a través de los cauces legales que existen para ello, y sin embargo los problemas se siguen sin resolver.
El 8 de marzo, dentro del marco de las reuniones de Madrid Accesibilidad TICs, se realizó una charla de la serie Pesadilla en Internet a los problemas de accesibilidad de la nueva web de Renfe. Ramón Corominas y Jesús Álvarez del Amo mostraron los principales problemas de accesibilidad de la web de Renfe. En el enlace anterior podemos encontrar los vídeos de esa charla.
En base a la información expuesta en la charla anterior, he realizado unos vídeos para explicar el problema. Hoy publico la primera parte, Accesibilidad de la web de Renfe (1):
Mañana publicaré la segunda parte en la que comento los principales problemas de accesibilidad que presenta la nueva web de Renfe. La tercera parte en la que se explica el problema más importante la realizará Ramón Corominas y la publicará en breve.
Y la transcripción del audio del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver unos problemas graves de accesibilidad que presenta el sitio web de Renfe.
Este vídeo consta de varias partes y ha sido realizado con la colaboración de Ramón Corominas y Jesús Álvarez del Amo, que realizaron una presentación sobre los problemas de la web de Renfe en el marco de las reuniones de “Madrid Accesibilidad TICS”.
En esta primera parte vamos a ver el porqué de estos vídeos sobre la accesibilidad de la web de Renfe.
El pasado 8 de febrero, Renfe cambió sus tarifas y aprovechó el cambio para introducir algunos cambios en su web.
El cambio de tarifas produjo un “efecto llamada” y fue masiva la afluencia de gente que visito la nueva web.
Desgraciadamente, durante las siguientes semanas, también fueron masivas las quejas de los usuarios que aparecieron en Twitter.
Los usuarios comentaban los graves problemas que tenían para usar la nueva web. En algunos casos era un misión imposible comprar un billete en la nueva web.
Los mensajes de queja siguieron durante los siguientes meses al estreno de la nueva web de Renfe.
Algunos mensajes también señalaban un problema importante, la falta de usabilidad de la web de Renfe.
En enero del año 2013, se publicó un trabajo en el que se analizaba la usabilidad de la web de Renfe,
y se comparaba con otras dos compañías europeas, las empresas ferroviarias nacionales de Alemania y de Francia.
Los resultados que obtuvo la web de Renfe no fueron muy buenos.
Así, por ejemplo, al comparar la eficiencia en la realización de ciertas tareas, en el caso de la web de Renfe, prácticamente 1 de cada 2 tareas era ineficiente, mientras que en el caso de la web alemana, eso ocurría, prácticamente, sólo en 1 de cada 10 casos, y en el caso de la web francesa, en casi 1 de cada 3 casos.
Y con respecto a la satisfacción general, la web de Renfe también obtenía peores resultados que las otras dos webs.
¿Qué le pasa a la web de Renfe? Estos problemas no son de ahora, son problemas que la web arrastra desde hace muchos años.
En una noticia publicada en el periódico digital eldiario.es poco después del estreno de la nueva web de Renfe, encontramos una posible explicación. La web de Renfe “es un engendro”, un monstruo de Frankenstein, en el que participan numerosas empresas y consultores.
Y ya se sabe lo que dice el refrán, “muchos cocineros, estropean el caldo”. Y más si son cocineros a los que les gusta comer bien.
Pero además de los problemas de usabilidad, lo que me interesa contar en este vídeo son los problemas de accesibilidad.
En Twitter también se publicaron algunas quejas sobre los problemas de accesibilidad de la nueva web.
En particular, José Ángel Carrey, un usuario ciego, se dirigió varias veces a Renfe para que resolviera los problemas de accesibilidad.
José Ángel Carrey se dirigió directamente a Renfe por varios medios, por Twitter, por Facebook y por correo electrónico.
La respuesta que obtenía de Renfe era siempre la misma: la nueva web es accesible o tiene algunos pequeños problemas que se están solucionando.
Sin embargo, casi 4 meses después del estreno de la nueva web de Renfe, los problemas siguen existiendo.
Pero, ¿la web de Renfe tiene que ser accesible?
Sí, en España existen diversas leyes que obligan a que la web de Renfe sea accesible.
Y no vale decir eso de que “son desarrollos nuevos y estamos subsanando los errores”.
La ley establece que los desarrollos nuevos tienen que ser accesibles desde el principio.
Ahora te invito a que veas la siguiente parte de este vídeo, en el que veremos los problemas concretos de accesibilidad que presenta la nueva web de Renfe.
Y con esto finaliza esta primera parte del vídeo dedicado a los problemas de accesibilidad de la nueva web de Renfe.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
Desgraciadamente, los cambios hicieron que los problemas de accesibilidad aumentaran, y ahora mismo una persona ciega que utilice un lector de pantallas no puede comprar un billete de tren ella sola.
José Ángel Carrey, un usuario ciego, se puso en contacto con Renfe para comunicar el problema, lo denuncio públicamente y a través de los cauces legales que existen para ello, y sin embargo los problemas se siguen sin resolver.
El 8 de marzo, dentro del marco de las reuniones de Madrid Accesibilidad TICs, se realizó una charla de la serie Pesadilla en Internet a los problemas de accesibilidad de la nueva web de Renfe. Ramón Corominas y Jesús Álvarez del Amo mostraron los principales problemas de accesibilidad de la web de Renfe. En el enlace anterior podemos encontrar los vídeos de esa charla.
En base a la información expuesta en la charla anterior, he realizado unos vídeos para explicar el problema. Hoy publico la primera parte, Accesibilidad de la web de Renfe (1):
Mañana publicaré la segunda parte en la que comento los principales problemas de accesibilidad que presenta la nueva web de Renfe. La tercera parte en la que se explica el problema más importante la realizará Ramón Corominas y la publicará en breve.
Y la transcripción del audio del vídeo:
Hola, soy Sergio Luján Mora, profesor de informática de la Universidad de Alicante, y este vídeo forma parte de una serie de videotutoriales dedicados a la accesibilidad web. En este vídeo vamos a ver unos problemas graves de accesibilidad que presenta el sitio web de Renfe.
Este vídeo consta de varias partes y ha sido realizado con la colaboración de Ramón Corominas y Jesús Álvarez del Amo, que realizaron una presentación sobre los problemas de la web de Renfe en el marco de las reuniones de “Madrid Accesibilidad TICS”.
En esta primera parte vamos a ver el porqué de estos vídeos sobre la accesibilidad de la web de Renfe.
El pasado 8 de febrero, Renfe cambió sus tarifas y aprovechó el cambio para introducir algunos cambios en su web.
El cambio de tarifas produjo un “efecto llamada” y fue masiva la afluencia de gente que visito la nueva web.
Desgraciadamente, durante las siguientes semanas, también fueron masivas las quejas de los usuarios que aparecieron en Twitter.
Los usuarios comentaban los graves problemas que tenían para usar la nueva web. En algunos casos era un misión imposible comprar un billete en la nueva web.
Los mensajes de queja siguieron durante los siguientes meses al estreno de la nueva web de Renfe.
Algunos mensajes también señalaban un problema importante, la falta de usabilidad de la web de Renfe.
En enero del año 2013, se publicó un trabajo en el que se analizaba la usabilidad de la web de Renfe,
y se comparaba con otras dos compañías europeas, las empresas ferroviarias nacionales de Alemania y de Francia.
Los resultados que obtuvo la web de Renfe no fueron muy buenos.
Así, por ejemplo, al comparar la eficiencia en la realización de ciertas tareas, en el caso de la web de Renfe, prácticamente 1 de cada 2 tareas era ineficiente, mientras que en el caso de la web alemana, eso ocurría, prácticamente, sólo en 1 de cada 10 casos, y en el caso de la web francesa, en casi 1 de cada 3 casos.
Y con respecto a la satisfacción general, la web de Renfe también obtenía peores resultados que las otras dos webs.
¿Qué le pasa a la web de Renfe? Estos problemas no son de ahora, son problemas que la web arrastra desde hace muchos años.
En una noticia publicada en el periódico digital eldiario.es poco después del estreno de la nueva web de Renfe, encontramos una posible explicación. La web de Renfe “es un engendro”, un monstruo de Frankenstein, en el que participan numerosas empresas y consultores.
Y ya se sabe lo que dice el refrán, “muchos cocineros, estropean el caldo”. Y más si son cocineros a los que les gusta comer bien.
Pero además de los problemas de usabilidad, lo que me interesa contar en este vídeo son los problemas de accesibilidad.
En Twitter también se publicaron algunas quejas sobre los problemas de accesibilidad de la nueva web.
En particular, José Ángel Carrey, un usuario ciego, se dirigió varias veces a Renfe para que resolviera los problemas de accesibilidad.
José Ángel Carrey se dirigió directamente a Renfe por varios medios, por Twitter, por Facebook y por correo electrónico.
La respuesta que obtenía de Renfe era siempre la misma: la nueva web es accesible o tiene algunos pequeños problemas que se están solucionando.
Sin embargo, casi 4 meses después del estreno de la nueva web de Renfe, los problemas siguen existiendo.
Pero, ¿la web de Renfe tiene que ser accesible?
Sí, en España existen diversas leyes que obligan a que la web de Renfe sea accesible.
Y no vale decir eso de que “son desarrollos nuevos y estamos subsanando los errores”.
La ley establece que los desarrollos nuevos tienen que ser accesibles desde el principio.
Ahora te invito a que veas la siguiente parte de este vídeo, en el que veremos los problemas concretos de accesibilidad que presenta la nueva web de Renfe.
Y con esto finaliza esta primera parte del vídeo dedicado a los problemas de accesibilidad de la nueva web de Renfe.
Si necesitas más información o quieres contactar conmigo, en mis páginas web http://accesibilidadweb.dlsi.ua.es y en http://desarrolloweb.dlsi.ua.es podrás encontrar más información sobre la accesibilidad web y el desarrollo web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es o a través de mi cuenta de Twitter @sergiolujanmora.
Muchas gracias por tu atención.
martes, 4 de junio de 2013
¿UNE 139803:2004 o UNE 139803:2012?
El 2 de octubre de 2012 se publicó en el Boletín Oficial del Estado la nueva Norma UNE 139803:2012. Esta Norma sustituye a la anterior Norma UNE 139803:2004 que establecía los requisitos de accesibilidad web que se debían aplicar en España. Básicamente, la antigua norma era igual a WCAG 1.0, mientras que la nueva norma es una adaptación de WCAG 2.0.
Desgraciadamente, la resolución que se publicó el 2 de octubre era simplemente un anuncio de las nuevas normas publicadas por AENOR, y se indicaban las normas antiguas que las nuevas sustituían, pero no aclaraba algunas dudas importantes:
Desgraciadamente, la resolución que se publicó el 2 de octubre era simplemente un anuncio de las nuevas normas publicadas por AENOR, y se indicaban las normas antiguas que las nuevas sustituían, pero no aclaraba algunas dudas importantes:
- Las leyes y reales decretos en materia de accesibilidad web hacen referencia a la antigua norma, ¿se actualizan automáticamente por la entrada en vigor de la nueva norma?
- ¿Qué ocurre con los sitios web que cumplían la antigua norma? ¿Se tienen que adaptar a la nueva?
- ¿Qué ocurre con los sitios web que se están desarrollando conforme a la antigua norma? ¿Se tienen que adaptar a la nueva antes de publicarse?
En definitiva, una situación bastante extraña, por no decir injusta y peligrosa. Un cambio tan importante debería de ir acompañado de un período de transición para adaptarse a la nueva norma. Y eso no se indicaba ni en esa resolución ni en posteriores.
Sin embargo, gracias a Álvaro D.Z., un lector de este blog, me ha llegado un documento con fecha 14 de mayo de 2013 de la Oficina Permanente Especializada, dependiente del Ministerio de Sanidad, Servicios Sociales e Igualdad, en el que se responde:
La Abogacía del Estado del Ministerio de Sanidad, Servicios Sociales e Igualdad, en contestación a una consulta elevada a instancia de la Subdirección General de Coordinación y Ordenación de la Dirección General de Políticas de Apoyo a la Discapacidad indicó como conclusión a una solicitud de informe que La Norma UNE de la AENOR 139803:2012 "Requisitos de accesibilidad para contenidos en la Web" sustituye a todos los efectos a la mencionada en el Real Decreto 1494/2007 con la referencia de niveles de accesibilidad y prioridades de la Norma UNE 139803:2004 sin necesidad de su incorporación o adaptación en una Orden Ministerial.
Por tanto, según dicho informe, es de aplicación, a todos los efectos, la Norma UNE 139803:2012.
¿Y si te ha pillado a medias de un desarrollo? Te fastidias...
¿Y qué hago con mis sitios web que cumplían la norma anterior? Misterio, misterioso...
lunes, 3 de junio de 2013
MouseGrid de Dragon Naturally Speaking
Dragon Naturally Speaking es un software de reconocimiento de voz que ya tiene bastantes años. Lo desarrolla una empresa llamada Nuance.
El reconocimiento de voz aún no está a la altura de lo que uno podría esperar... pero ha mejorado mucho bastante hace años. Ya no hace falta entrenar al sistema durante varias horas, aunque sí que necesita un entrenamiento previo de varios minutos.
Dragon es usado por muchas personas con problemas motores o de movilidad para utilizar el ordenador, ya que permite manejar el ordenador simplemente con la voz.
Una opción muy interesante que posee es MouseGrid. La podemos en la página 61 de la guía del usuario de Dragon Naturally Speaking (versión 11).
Esta tecnología permite situar el cursor del ratón en cualquier parte de la pantalla mediante unos comandos de voz.
Para ello se tiene que activar la opción "Dividir pantalla", que dibuja una cuadrícula sobre la pantalla. También se puede decir "Dividir ventana" para situar la cuadrícula sobre la ventana activa.
Al decir un número del 1 al 9 se coloca el cursor en el área numerada. Por ejemplo, en la imagen anterior, para activar la "Papelera de reciclaje", primero habría que decir "4". A continuación, el área de pantalla seleccionada se divide en una cuadrícula más pequeña.
Ahora, para activar la "Papelera de reciclaje" habría que volver a decir "4".
Este proceso se puede repetir tantas veces como haga falta hasta que el cursor del ratón se sitúa sobre un icono, un botón, un enlace u otro objeto similar.
Una vez situado el cursor del ratón, se puede hacer clic, doble clic, botón derecho, arrastrar, etc.
El reconocimiento de voz aún no está a la altura de lo que uno podría esperar... pero ha mejorado mucho bastante hace años. Ya no hace falta entrenar al sistema durante varias horas, aunque sí que necesita un entrenamiento previo de varios minutos.
Dragon es usado por muchas personas con problemas motores o de movilidad para utilizar el ordenador, ya que permite manejar el ordenador simplemente con la voz.
Una opción muy interesante que posee es MouseGrid. La podemos en la página 61 de la guía del usuario de Dragon Naturally Speaking (versión 11).
Esta tecnología permite situar el cursor del ratón en cualquier parte de la pantalla mediante unos comandos de voz.
Para ello se tiene que activar la opción "Dividir pantalla", que dibuja una cuadrícula sobre la pantalla. También se puede decir "Dividir ventana" para situar la cuadrícula sobre la ventana activa.
Al decir un número del 1 al 9 se coloca el cursor en el área numerada. Por ejemplo, en la imagen anterior, para activar la "Papelera de reciclaje", primero habría que decir "4". A continuación, el área de pantalla seleccionada se divide en una cuadrícula más pequeña.
Ahora, para activar la "Papelera de reciclaje" habría que volver a decir "4".
Este proceso se puede repetir tantas veces como haga falta hasta que el cursor del ratón se sitúa sobre un icono, un botón, un enlace u otro objeto similar.
Una vez situado el cursor del ratón, se puede hacer clic, doble clic, botón derecho, arrastrar, etc.
viernes, 31 de mayo de 2013
El nivel de cumplimiento de la accesibilidad web en Europa
Interesante el informe realizado por la Comisión Europea en el año 2009: Study report: Web accessibility in European countries: level of compliance with latest international accessibility specifications, notably WCAG 2.0, and approaches or plans to implement those specifications.
Este informe presenta los resultados de un estudio para proporcionar datos y análisis para apoyar a la Comisión Europea en la identificación de nivel de implantación de la accesibilidad web en la Unión Europea. El objetivo del estudio era aportar pruebas y análisis para ayudar a entender y comparar los enfoques adoptados por los países europeos, con el fin de identificar los problemas y desafíos, buenas prácticas y las prioridades futuras en el ámbito de la accesibilidad web. Un aspecto central de este informe es sobre el tema de la transición a las pautas WCAG 2.0 en el contexto actual en que los Estados miembros, en su mayoría, están dirigiendo sus esfuerzos hacia las anteriores pautas WCAG 1.0.
El informe está divido en tres documentos en formato PDF. En la tercera parte,Overview of Accessibility Related Obligations Imposed on Website Owners in Selected Member States and of National Sources of Data on Compliance, se ofrece una comparativa de las legislaciones en materia de accesibilidad web de diferentes países europeos.
Este informe presenta los resultados de un estudio para proporcionar datos y análisis para apoyar a la Comisión Europea en la identificación de nivel de implantación de la accesibilidad web en la Unión Europea. El objetivo del estudio era aportar pruebas y análisis para ayudar a entender y comparar los enfoques adoptados por los países europeos, con el fin de identificar los problemas y desafíos, buenas prácticas y las prioridades futuras en el ámbito de la accesibilidad web. Un aspecto central de este informe es sobre el tema de la transición a las pautas WCAG 2.0 en el contexto actual en que los Estados miembros, en su mayoría, están dirigiendo sus esfuerzos hacia las anteriores pautas WCAG 1.0.
El informe está divido en tres documentos en formato PDF. En la tercera parte,Overview of Accessibility Related Obligations Imposed on Website Owners in Selected Member States and of National Sources of Data on Compliance, se ofrece una comparativa de las legislaciones en materia de accesibilidad web de diferentes países europeos.
jueves, 30 de mayo de 2013
¿Deben las Administraciones Públicas informar sobre el nivel de accesibilidad de sus páginas web?
Sí, así lo indica la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información, que modifica varios apartados de la Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico.
En concreto, en el Artículo 4. Modificaciones de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico, en el apartado diecinueve se dice:
En concreto, en el Artículo 4. Modificaciones de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico, en el apartado diecinueve se dice:
Se añaden dos nuevos párrafos, que pasarán a ser respectivamente el tercero y el cuarto, al apartado uno de la disposición adicional quinta, con el texto siguiente:¿Lo cumplen todas? Está claro que no.
Las Administraciones Públicas exigirán que tanto las páginas de Internet cuyo diseño o mantenimiento financien total o parcialmente como las páginas de Internet de entidades y empresas que se encarguen de gestionar servicios públicos apliquen los criterios de accesibilidad antes mencionados. En particular, será obligatorio lo expresado en este apartado para las páginas de Internet y sus contenidos de los Centros públicos educativos, de formación y universitarios, así como, de los Centros privados que obtengan financiación pública.
Las páginas de Internet de las Administraciones Públicas deberán ofrecer al usuario información sobre su nivel de accesibilidad y facilitar un sistema de contacto para que puedan transmitir las dificultades de acceso al contenido de las páginas de Internet o formular cualquier queja, consulta o sugerencia de mejora.
miércoles, 29 de mayo de 2013
La velocidad de conexión también es una barrera de accesibilidad
Las condiciones técnicas de acceso a Internet también se pueden estudiar y resolver desde el punto de vista de la accesibilidad web. Por ejemplo, un usuario con una conexión lenta a Internet puede desactivar la carga de las imágenes para que las páginas se carguen más rápidamente en su navegador. Pero entonces, el usuario pasará a convertirse en un "usuario ciego temporal".
Yagruma es un sitio web dedicado a proyectos culturales y creativos en Cuba. Para el que no lo sepa, en Cuba (y también en otros muchos países), la conexión a Internet no es muy rápida.
Para ayudar a reducir el impacto de las conexiones lentas, en Yagruma ofrecen la opción de elegir el tipo de conexión, lenta o rápida:
En el área de preguntas y respuestas de este sitio web nos explican que la conexión lenta comprime todas las imágenes, hasta un 70% en algunos casos: a cambio de un pequeño sacrificio en la calidad de las imágenes, se logra una reducción en el tiempo de carga de las páginas.
A continuación tenemos un ejemplo de dos imágenes, la primera es la versión de la conexión rápida y la segunda es la versión para la conexión lenta. Podemos ver que en el segundo caso aparece el famoso ruido de JPG cuando la calidad es baja.
Imagen de la versión rápida, 101 KB:
Imagen de la versión lenta, 26,1 KB:
Otra técnica que se puede aplicar para mejorar la velocidad de descarga, en realidad, para mejorar la percepción del usuario (porque en realidad no se mejora la velocidad de descarga), es utilizar imágenes en formato JPEG progresivo. ¿No sabes lo que es? En Progressive jpegs: a new best practice te lo cuentan.
Yagruma es un sitio web dedicado a proyectos culturales y creativos en Cuba. Para el que no lo sepa, en Cuba (y también en otros muchos países), la conexión a Internet no es muy rápida.
Para ayudar a reducir el impacto de las conexiones lentas, en Yagruma ofrecen la opción de elegir el tipo de conexión, lenta o rápida:
En el área de preguntas y respuestas de este sitio web nos explican que la conexión lenta comprime todas las imágenes, hasta un 70% en algunos casos: a cambio de un pequeño sacrificio en la calidad de las imágenes, se logra una reducción en el tiempo de carga de las páginas.
A continuación tenemos un ejemplo de dos imágenes, la primera es la versión de la conexión rápida y la segunda es la versión para la conexión lenta. Podemos ver que en el segundo caso aparece el famoso ruido de JPG cuando la calidad es baja.
Imagen de la versión rápida, 101 KB:
Imagen de la versión lenta, 26,1 KB:
Otra técnica que se puede aplicar para mejorar la velocidad de descarga, en realidad, para mejorar la percepción del usuario (porque en realidad no se mejora la velocidad de descarga), es utilizar imágenes en formato JPEG progresivo. ¿No sabes lo que es? En Progressive jpegs: a new best practice te lo cuentan.
martes, 28 de mayo de 2013
Ivona Text-to-Speech
Ivona es una empresa que desarrolla voces para sintetizadores de voz (sistemas text-to-speech).
La calidad es realmente impresionante, y podemos probarlo online. Podemos probarlo con una voz de "español castellano" o "español americano".
La calidad es realmente impresionante, y podemos probarlo online. Podemos probarlo con una voz de "español castellano" o "español americano".
lunes, 27 de mayo de 2013
Voces para JAWS
En el sitio web del fabricante de JAWS, Freedom Scientific, se puede encontrar una página desde la que se pueden descargar diferentes voces con dos niveles de calidad: Vocalizer Direct Voices.
Podemos encontrar voces para el español-español, para el español latinoamericano y para el vasco (Arantxa) y para el catalán (Nuria).
Podemos encontrar voces para el español-español, para el español latinoamericano y para el vasco (Arantxa) y para el catalán (Nuria).
sábado, 25 de mayo de 2013
Desactivar un diseño web adaptable (responsive web design)
El diseño web adaptable no es la mejor solución para todos los casos. Además, puede haber usuarios que tengan dificultades de uso de un sitio web si cambia su presentación al acceder desde diferentes dispositivos. Por eso, hay gente que ha desarrollado técnicas para desactivar estos diseños, como podemos leer en estos artículos:
viernes, 24 de mayo de 2013
Las rampas y los extraterrestres
Hace unos días, me encontré el siguiente "tuit" en el artículo Neil deGrasse Tyson: How Space Exploration Can Make America Great Again:
Why do aliens always disembark via ramp? Do they have problems with stairs? Or are flying saucers just handicap-accessible?
Traducido:
¿Por qué los extraterrestres siempre desembarcan mediante una rampa? ¿Tienen problemas con las escaleras? ¿O es que los platillos voladores son simplemente accesibles para los discapacitados?
Neil deGrasse Tyson es un famoso astrofísico y divulgador científico. El tuit anterior está extraído de su libro "Space Chronicles: Facing the Ultimate Frontier".
Hace que pensar... en las películas aparecen los platillos voladores como máquinas voladoras equipadas con tecnologías que no existen en la Tierra.
¿Son las rampas una tecnología por inventar en la Tierra?
jueves, 23 de mayo de 2013
Eficiencia y Ahorro con la Aplicación de Tecnologías Accesibles en las Administraciones Públicas
El próximo lunes 27 de mayo el CENTAC (Centro Nacional de Tecnologías de la Accesibilidad) realiza la presentación del informe Eficiencia y Ahorro con la Aplicación de Tecnologías Accesibles en las Administraciones Públicas.
Tengo mucho interés en ver ese informe, porque una cosa es decir que la accesibilidad no cuesta mucho y otra es decir que incluso permite el ahorro. Quiero saber cómo se logra eso y este informe parece que tiene la clave para ello.
El evento será retransmitido por Internet vía streaming y accesible mediante subtitulación en directo e intérpretes de lengua de signos.
Tengo mucho interés en ver ese informe, porque una cosa es decir que la accesibilidad no cuesta mucho y otra es decir que incluso permite el ahorro. Quiero saber cómo se logra eso y este informe parece que tiene la clave para ello.
El evento será retransmitido por Internet vía streaming y accesible mediante subtitulación en directo e intérpretes de lengua de signos.
miércoles, 22 de mayo de 2013
Un problema importante con ocultar las listas
La teoría dice que aquello que sea una lista lo debes etiquetar como una lista. Por ejemplo, una lista de enlaces. Por ejemplo, los enlaces que forman un menú.
La teoría también dice que si no te gusta la apariencia de la lista, la puedes cambiar con CSS con la propiedad list-style-type o list-style. Con el valor none se logra que la lista no aparezca marcada, pero sigue siendo una lista.
La teoría también dice que los lectores de pantalla seguirán leyendo las listas como listas, sea cual sea su apariencia visual. Los lectores de pantalla ofrecen facilidades para que el usuario se mueva por una lista, como por ejemplo indicarle cuántos elementos tiene la lista y en qué posición en la lista se encuentra en un momento dado.
Esta es la teoría que podemos leer en muchos sitios. Es una teoría "bonita" que tiene mucho sentido.
Pues no, porque parece que la teoría no siempre se cumple.
En el artículo Screen readers, list items and list-style: none nos explican que esto no siempre funciona así. El autor ha hecho pruebas con los lectores de pantalla NVDA, Orca y VoiceOver y ha descubierto que estos navegadores no anuncian las listas cuando list-style-type o list-style toman el valor none.
¿Y qué pasa con JAWS? En el artículo no aparece.
La teoría también dice que si no te gusta la apariencia de la lista, la puedes cambiar con CSS con la propiedad list-style-type o list-style. Con el valor none se logra que la lista no aparezca marcada, pero sigue siendo una lista.
La teoría también dice que los lectores de pantalla seguirán leyendo las listas como listas, sea cual sea su apariencia visual. Los lectores de pantalla ofrecen facilidades para que el usuario se mueva por una lista, como por ejemplo indicarle cuántos elementos tiene la lista y en qué posición en la lista se encuentra en un momento dado.
Esta es la teoría que podemos leer en muchos sitios. Es una teoría "bonita" que tiene mucho sentido.
Pues no, porque parece que la teoría no siempre se cumple.
En el artículo Screen readers, list items and list-style: none nos explican que esto no siempre funciona así. El autor ha hecho pruebas con los lectores de pantalla NVDA, Orca y VoiceOver y ha descubierto que estos navegadores no anuncian las listas cuando list-style-type o list-style toman el valor none.
¿Y qué pasa con JAWS? En el artículo no aparece.
martes, 21 de mayo de 2013
Personas: personajes ficticios para tests de accesibilidad
El concepto persona (usado así en inglés) se emplea en diferentes áreas, como el marketing, para representan un personaje ficticio, al que se le suele dar un nombre y una serie de características concretas.
En usabilidad y en el diseño centrado en el usuario se emplea este término para representar personajes ficticios que no son personas reales, pero que podrían serlo.
En el artículo Accessibility in User-Centered Design: Personas se proporcionan algunas pautas para aplicar esta técnica a la accesibilidad.
Por ejemplo, lo siguiente es una descripción de una posible "persona":
Hanna is moving up the corporate ladder. Her goal is to replace the current HR manager when he retires in three years. Hanna prides herself on being fast, efficient, and precise. She stakes her reputation on the month-end reports that show how many transactions she has completed in comparison to her colleagues.
Hanna, who has been blind since birth, uses a screen reader when she works on the computer. She has used jaws as her screen reader for the past 5 years. Hanna has worked hard to master the long list of key combinations in jaws and she is proud of her speed and accuracy.
Hanna struggles with balancing work life and family life. She works from home on Tuesdays and Thursdays so that she can be with her kids. Her computer setup at home is much older and slower than the one at work and she sometimes gets frustrated because she feels limited when working at home.
Hanna's home computer has an older version of jaws. She sometimes attempts to use key combinations at home that only function on the newer version of jaws she has at work. As a result, she often finds herself repeating steps. She reads Braille, but she doesn't use a refreshable Braille display either at work or at home.
Hanna likes corresponding with other jaws users through email. She has learned tips and tricks from her online friends and has found that each person has a unique setup and that everyone uses jaws a little differently.
Hanna views her computer as a helpful and (mostly) enjoyable tool to help her climb to the top. Hanna has one big hang-up related to using the computer – she hates to ask for help. She will spend hours trying to figure something out on her own, rather than admit that she doesn't know what to do.
lunes, 20 de mayo de 2013
La ley de transparencia y el Ministerio de Sanidad
Anoche, el programa Salvados de la Sexta emitió Sin transparencia, que trató el tema de la ley de transparencia que se está tramitando en España.
Hace poco más de un año, el Gobierno habilitó el sitio web Ley de transparencia para que cualquiera pudiera aportar comentarios y sugerencias al proyecto de esta ley.
Desgraciadamente, fue una demostración bastante burda de "transparencia", tal como comenté en mi entrada La Ley de Transparencia, Acceso a la Información Pública y Buen Gobierno empieza mal, muy mal.
Básicamente, era mentira que pudiera participar cualquiera, ya que el formulario para enviar una sugerencia tenía un captcha visual que suponía una barrera de accesibilidad para diferentes grupos de usuarios, como los usuarios ciegos, los usuarios con baja visión o los usuarios con problemas cognitivos.
Pero además, ¿dónde estaban las aportaciones que habían podido haber hecho otros ciudadanos? ¿Por qué no se permitía un debate abierto? ¿Por qué no se podía verificar si las sugerencias que habían hecho los ciudadanos se habían tenido en cuenta en la modificación de la ley? Tal como estaba montado el sistema, la transparencia y el acceso a la información era nula.
Desgraciadamente, fue una demostración bastante burda de "transparencia", tal como comenté en mi entrada La Ley de Transparencia, Acceso a la Información Pública y Buen Gobierno empieza mal, muy mal.
Básicamente, era mentira que pudiera participar cualquiera, ya que el formulario para enviar una sugerencia tenía un captcha visual que suponía una barrera de accesibilidad para diferentes grupos de usuarios, como los usuarios ciegos, los usuarios con baja visión o los usuarios con problemas cognitivos.
Pero además, ¿dónde estaban las aportaciones que habían podido haber hecho otros ciudadanos? ¿Por qué no se permitía un debate abierto? ¿Por qué no se podía verificar si las sugerencias que habían hecho los ciudadanos se habían tenido en cuenta en la modificación de la ley? Tal como estaba montado el sistema, la transparencia y el acceso a la información era nula.
Una ley de transparencia es necesaria para evitar cosas como la imposibilidad de obtener información básica del Estado que rige nuestras vidas.
Por ejemplo, desde hace más de un año estoy reclamando información al Ministerio de Sanidad sobre las denuncias por falta de accesibilidad web presentadas en España:
Sin embargo, ya ha pasado más de un mes desde la última comunicación y sigo esperando.
[Actualización 22/05/2013]
Un artículo publicado en la revista Eroski Consumer: ¿Por qué es importante la transparencia institucional en la era de Internet?
En este artículo se puede leer:
[Actualización 22/05/2013]
Un artículo publicado en la revista Eroski Consumer: ¿Por qué es importante la transparencia institucional en la era de Internet?
En este artículo se puede leer:
El Gobierno español tramita un proyecto de ley de transparencia y buen gobierno, cuyo borrador puede consultarse en Internet. Esta ley también tuvo una consulta pública entre los meses de marzo y abril. Recibió 3.683 aportaciones de particulares, empresas, ONG y desde dentro de la propia Administración. Además, la web del anteproyecto tuvo durante sus primeras semanas más de 80.000 visitas, fruto del interés social por el desarrollo de esta norma. A pesar de esto, muchos de sus informes internos se han conocido mediante filtraciones en los medios. Además, algunas asociaciones civiles como Access Info consideran que el redactado actual de la ley no cumple con los estándares internacionales de transparencia.
sábado, 18 de mayo de 2013
Vídeo de los fundadores de NVDA
Los fundadores de NV Access, la organización que desarrolla el lector de pantallas NVDA, han publicado un vídeo para animar a la gente a realizar donaciones, ya que este lector de pantallas es gratuito.
Suscribirse a:
Entradas (Atom)