Buscador

viernes, 19 de octubre de 2007

Siete errores de accesibilidad que no se deben cometer

Acabo de encontrar el artículo Seven accessibility mistakes you don’t want to make. Son consejos muy generales, más bien destinados a un jefe de proyectos que a un programador que se tenga que pelear con el HTML para que una página sea accesible, pero puede venir bien leerlo.

Los siete errores que se citan son:
  1. Believing in products without putting them to the test (creer en los productos sin probarlos).
  2. Taking too much responsibility (asumir demasiada responsabilidad).
  3. Planning only for the worst-case scenario (planificar únicamente para el peor caso).
  4. Sharing problems with the visitor (compartir los problemas con el visitante).
  5. Trying to solve problems outside our area of experience (intentar resolver los problemas que están fuera del área de experiencia).
  6. Hiding or overriding accessibility/usability enhancements (esconder o pasar por alto las mejoras de accesibilidad/usabilidad).
  7. Catering to your client–not their clients (abastecer a tu cliente, no a sus clientes).

Mejores blogs sobre accesibilidad y usabilidad web en español

He encontrado una entrada en el blog Accesibilidad, Usabilidad y Estandares Web titulada Mejores blogs sobre accesibilidad y usabilidad web en español. El propósito del autor era recopilar una lista con los 100 mejores blogs sobre accesibilidad en español. Inicialmente tenía 60 direcciones, pero ya va por 105.

Desde aquí le agradezco al autor de este blog que me haya incluido en su lista :-)

miércoles, 17 de octubre de 2007

Accesibilidad de los productos de IBM

He encontrado la página web Accessibility and ergonomic comfort features of IBM personal computers and accessories donde se explican las características para mejorar la accesibilidad que incorporan algunos de los productos de IBM.

jueves, 11 de octubre de 2007

SMIL y la accesibilidad web

He recibido un correo electrónico en el que me preguntan si conozco algún editor de SMIL que permita realizar subtitulado y utilizar el lenguaje de signos. He tenido que contestar que lo desconozco. Pero... ¿qué es SMIL?

SMIL es el acrónimo de Synchronized Multimedia Integration Language, una recomendación del W3C que se emplea para describir presentaciones multimedia, es decir, presentaciones donde podemos combinar texto (con formato), imágenes, audio y vídeo. SMIL es un lenguaje de marcado basado en XML.

Como de costumbre, Microsoft tiene una tecnología con un propósito similar llamada SAMI (Synchronized Accessible Media Interchange).

Para trabajar con cualquiera de las dos tecnologías necesitamos una herramienta de autor para crear el contenido y un reproductor compatible para poderlo visualizar.

En el caso de SMIL, algunos reproductores compatibles son Apple QuickTime, RealPlayer o Microsoft Windows Media Player. En el caso de SAMI, Microsoft Windows Media Player es compatible con esta tecnología.
Ambas tecnologías se pueden emplear para proporcionar subtítulos y transcripciones de la pista sonora de algún elemento multimedia de nuestras páginas web como los vídeos. Con esta tecnología podemos sincronizar los subtítulos y cualquier otro elemento con el vídeo.

En la página Webcasting Samples se pueden encontrar varios ejemplos para diferentes reproductores multimedia. A continuación incluyo dos ejemplos con dos estilos diferentes, uno integrado en la propia página web y otro que hace uso de forma externa del reproductos Microsoft Windows Media Player:

Otra certificación de la accesibilidad web

He encontrado otra certificación de la accesibilidad web: Etiqueta Europea (Accesibilidad Web): Euracert. Según dice en la propia web, "La etiqueta Euracert no es otra etiqueta sobre Accesibilidad Web. De hecho, un sitio web obtiene la etiqueta Euracert como añadido a una etiqueta local otorgada en un país europeo por una de las organizaciones existentes [...]". Esta certificación permite un reconocimiento mutuo entre organizaciones de distintos países que trabajan sobre las pautas y recomendaciones internacionales de accesibilidad.

Hace unos meses comenté en la entrada Certificación Accesibilidad Web otro tipo de certificación que existe y que está respaldada por el European Software Institute (ESI) y la Fundación CTIC.

¿Tiene un sentido tantas certificaciones? ¿Habra una certificación para las certificaciones?

El lenguaje de signos reconocido como lengua natural de las personas sordas

He encontrado esta noticia en el periódico El País: El orgullo sordo. Según cuenta la noticia, el Senado español acaba de reconocer el lenguaje de signos como lengua natural de las personas sordas.

Esta noticia me ha recordado una entrada titulada Simplificar los textos que escribí hace unos meses. En esta entrada explicaba que la redacción de los textos de una página web se tiene que simplificar para facilitar su lectura a las personas sordas ya que para ellas su lengua natural es el lenguaje de signos.

Como medio para mejorar la accesibilidad de un sitio web para las personas sordas se pueden incorporar vídeos con explicaciones en el lenguaje de signos. En aquella entrada ponía como ejemplo la web del banco Bankinter.

He encontrado un ejemplo más de uso del lenguaje de signos en una página web: Movistar. En este sitio web podemos encontrar varios vídeos que explican los servicios que ofrece Movistar mediante el lenguaje de signos.

Por otro lado, existe el documento Directrices para el uso del Lenguaje de Signos en la Red donde se explica cómo incorporar el lenguaje de signos a la web. En esta página se proporcionan consejos para grabar un vídeo e incluirlo en una página web.

domingo, 7 de octubre de 2007

aDesigner

Los creadores de IBM Home Page Reader han creado una nueva herramienta para evaluar la accesibilidad de un sitio web: aDesigner. Y es gratuita.

Además de evaluar la accesibilidad según las pautas del W3C o Section 508, esta herramienta realiza dos análisis y simulaciones muy interesantes: cómo ve la página web una persona completamente ciega que utilice un lector de pantallas o cómo ve una página web con una visión reducida (por la edad o por alguna enfermedad).

En el caso de las personas ciegas, esta herramienta muestra el tiempo necesario (en segundos y con un código de colores) para llegar a distintos puntos de la página cuando se accede a ella con un lector de pantalla. Cuando una página contiene muchas zonas oscuras significa que se tarda mucho tiempo en llegar a ellas; este problema se puede resolver con enlaces intradocumentales del tipo salta contenido (skip content).

En el caso de las personas con una visión reducida, esta herramienta permite simular distintas situaciones, como falta de agudeza visual o problemas de ceguera a algunos colores (daltonismo).


aDesigner también permite evaluar la accesibilidad de documentos ODF, de contenido Flash y de entornos gráficos de usuario.

Por último, esta herramienta se integra con Internet Explorer, ya que al instalarse añade al menú Herramientas la opción "Open with aDesigner".

viernes, 5 de octubre de 2007

Más sobre compatibilidad con distintos navegadores

Lograr que una misma página web sea compatible (funcione correctamente) con múltiples navegadores es una cuestión bastante compleja hoy en día. La mejor forma de lograrlo es:
  1. Emplear los estándares.
  2. Visualizar la página web en distintos navegadores para comprobar que es compatible.
Para visualizar una página web en distintos navegadores se podría pensar que haría falta tener un ordenador para cada navegador. Pero esa no es la única solución y, evidentemente, la mejor solución.

Hace ya unos meses escribí la entrada Como se ve mi página en distintos navegadores y Cómo instalar varias versiones de Internet Explorer en un mismo ordenador.

Ahora he encontrado el artículo Browser Tests, Services and Compatibility Test Suites que explica con detalle tres escenarios: como instalar varias versiones de Internet Explorer, como instalar varias versiones de Safari (el navegador más utilizado en Mac OS) y como instalar o utilizar varios navegadores en Linux.

Además, el artículo incluye una lista de herramientas disponibles a través de Internet que se pueden emplear para ver una página web en distintos navegadores.

En la página How to Check Your Website with Multiple Browsers on a Single Machine (Cross-Browser Compatibility Checking) se puede leer otra explicación de este problema.

(Actualización 07/10/2007) Me han informado de la existencia de la página Prueba tu página con diferentes navegadores donde también se comenta la necesidad de verificar la correcta visualización de una página web con diferentes navegadores. En esta página se incide en la necesidad de emplear navegadores alternativos y se ofrecen enlaces a algunos de ellos.

Un mini navegador muy potente

Acabo de encontrar una página web donde se puede probar Opera Mini, el navegador de Opera que se incluye en algunos móviles.

El simulador es muy bueno y el navegador es bastante asombroso, ya que muestra las páginas no con su aspecto original, sino modificadas, pero parece que es bastante "inteligente", ya que las modificaciones que introduce son muy acertadas (por ejemplo, adaptación de una página cuando se emplean tablas para maquetar el contenido).

Esta herramienta puede ser muy últil para evaluar la accesibilidad de una página web desde distintos dispositivos.

A continuación he incluido algunas capturas de visualización de la página web de la Universidad de Alicante con este navegador:






jueves, 4 de octubre de 2007

Hijax: Ajax accesible

Acabo de encontrar un nuevo término: Hijax. Bajo este término se esconde una estrategia de uso de Ajax que tiene el objetivo de lograr páginas web accesibles: que las páginas sean totalmente funcionales para aquellos usuarios que no puedan hacer uso de Ajax (por ejemplo, porque quieren o no pueden hacer uso de JavaScript).

Esta técnica se basa en lo que se conoce en inglés como progressive enhancement y graceful degradation, dos estrategias que permiten que un sistema informático (en este caso, una página web) funcione correctamente aun en el caso de que falte algún tipo de componente.

Mientras que con progressive enhancement se parte de una versión básica completamente operativa (se parte de una página web compatible con la mayoría de los navegadores y con el menor uso posible de tecnologías complementarias como CSS o JavaScript), con graceful degradation se parte del extremo contrario: se crea una página web para los últimos navegadores, con la posibilidad de que funcione en navegadors antiguos.

En el caso de Hijax, la estrategia que se emplea para lograr el progressive enhancement es la siguiente:
  1. Primero, diseñar un sitio web al "estilo antiguo", con enlaces y acciones de formularios que envían información al servidor y este devuelve una página completa con cada petición.
  2. A continuación, emplear JavaScript para capturar todos los enlaces y las acciones de los formularios para enviar la infomación mediante XMLHttpRequest. De este modo se puede seleccionar que parte de la página se pueden actualizar de forma individual en vez de tener que recargar toda la página.
Se puede encontrar más de información sobre este tema en esta página: Hijax.


Actualización (12/11/2007) Unas páginas con información interesante sobre Ajax y accesibilidad:

Actualización (21/11/2007) Un nuevo término sobre Ajax y la accesibilidad web: AxsJax. Más información en este comentario y en este otro.

miércoles, 3 de octubre de 2007

Otra noticia sobre IBM

Desde hace años, IBM está muy comprometida con el tema de la accesibilidad en la Web. En esta entrevista a Chieko Asakawa, Q&A: IBM seeks to make streaming media accessible to visually impaired, se describe un nuevo sistema que permite a los usuarios con problemas visuales acceder al contenido multimedia de las páginas web.

IBM Makes Software, Web, Accessibility Push

He encontrado esta página IBM Makes Software, Web, Accessibility Push que anuncia que IBM juntos con unas universidades norteamericanas está preparando material educativo sobre la accesibilidad web:

You might take using a computer for granted, but for millions of people, it's a challenge. One in five individuals, or over 54 million Americans, has a disability that makes it difficult to see a computer screen or navigate the Web, according to IBM.


Specialized, usually expensive, software and hardware solutions have long existed. And in recent years, certain helpful facilities have been built into mainstream software, like magnification for the visually impaired.


But IBM wants to broaden development for the needs of the disabled at a fundamental teaching level. A recent survey of 200 two and four-year U.S. universities commissioned by the computer giant found that the majority of
faculty do not teach accessibility in the classroom.


Today IBM announced an initiative to give teachers wider access to learning material about assistive technologies. Six university partners have signed on to start and the U.S. Department of Education is also supporting the initiative. IBM is building a worldwide repository of materials it said will enable student developers to make software more accessible to those with disabilities and the aging population.


"To create a truly inclusive society, all forms of information technology need to be more accessible," said Dr. Bonnie Jones of the U.S. Department of Education. "If we can't do this, people with disabilities land on the wrong side of the 'digital divide.' We have to capture the intelligence and imagination of our next generation of IT developers now."


The University of Illinois, California State University at Long Beach, Georgia Tech, University of Toronto and the Rochester Institute of Technology are some of the universities who are already working with IBM to build a repository of repeatable learning materials to incorporate into everyday computer programming classes.


In one example, the University of Illinois recently added an online course out universal Web site design that includes accessibility for people with disabilities.


"What's so exciting to me, and so important, is trying to get ahead of the curve and influence colleges around the world to change the way they teach," said Benjamin Kempner, program director, marketing and strategy for the IBM human ability and accessibility center.


"The result is going to be that IBM, or let's say AT&T, Verizon and other companies, will be able to employ people who understand accessibility, it's not an afterthought. Once you build accessibility into your products, that means giving millions of people, productive, fulfilling work," Kempner told internetnews.com. "It can also mean more Web sites will be created that consumers can access."


Kempner spoke during his attendance at the 2007 Technology & Persons with Disabilities Conference at the California State University at Northridge. IBM awarded prizes to three students who won a contest related to the Open Document Format for interoperability.


Daniel Millington (Capitol College), Chase Pritchett (University of Oklahoma), and Yang Liu (Tsinghua University in China), wrote computer code that checks word processing documents that adhere to the ODF to determine whether they are accessible. The students contributed their code to the open source community via sourceforge.org.


Separately, Kempner mentioned other accessibility projects in which IBM is involved. For example, one software/hardware product IBM co-developed with another firm is designed to help people with tremors better control a computer mouse. Another, ViaScribe, is being used by 15 universities worldwide. Used in conjunction with a microphone, ViaScribe is speech recognition software that course instructors can use to get their spoken words on a computer screen so the deaf and hard of hearing can follow along.


To IBM's surprise, ViaScribe proved valuable to more than those with hearing loss. "We've created a mine-able resource that students can use look up lectures on the Web," said Kempner. "As we develop more of these technologies, there will be a larger societal benefit."


En esta página de IBM se puede encontrar toda la información.

viernes, 28 de septiembre de 2007

Metodología revisión accesibilidad

Acabo de encontrar esta interesante página web: Metodología práctica de revisión de la accesibilidad de sitios Web. En esta página se comentan las ventajas y desventajas de la revisión manual y la revisión automática de la accesibilidad y se propone una metodología práctica de revisión de la accesibilidad de los sitios web que combina ambos métodos.

La metodología de revisión de la accesibilidad consta de cuatro pasos:
  1. Análisis con navegador sólo-texto
    Se recomienda usar BrailleSurf o alternativamente usar el simulador Lynx-me disponible mediante un formulario Internet para intenta navegar por el sitio usando este tipo de interfaz sólo texto. Es importante probar así antes de ver la página con el navegador gráfico, para ver si se entiende correctamente la estructura del sitio web.
  2. Análisis con navegador gráfico habitual
    Comprobar en Netscape o Explorer el lugar donde se producen fallos con la versión
  3. Análisis con navegador Opera
    Opera es un navegador gráfico gratuito con muchas funciones de accesibilidad y alta capacidad de configuración lo que permite comprobar fácilmente distintas situaciones que ayuden a detectar problemas de accesibilidad.
  4. Análisis final con Bobby o Taw (opcional)
    Es importante realizar este análisis final que confirmará si hemos olvidado verificar alguno de los aspectos fundamentales de accesibilidad recogidos en las pautas WAI.

martes, 25 de septiembre de 2007

Artículo sobre la accesibilidad de algunos sitios web de las administraciones públicas españolas

El artículo La accesibilidad en los sitios web de instituciones públicas españolas fue publicado en el IV Congreso Iberoamericano de informática en la Educación Especial. Aplicaciones para la calidad de vida,  Madrid (2003).

martes, 18 de septiembre de 2007

I Plan Nacional de Accesibilidad 2004-2012

El I Plan Nacional de Accesibilidad 2004-2012, publicado por el Ministerio de Trabajo y Asuntos Sociales.

jueves, 13 de septiembre de 2007

Los captcha y la accesibilidad web

¿Qué es un captcha? Según la Wikipedia:
Captcha es el acrónimo de Completely Automated Public Turing test to tell Computers and Humans Apart (Prueba de Turing pública y automática para diferenciar a máquinas y humanos).

Se trata de una prueba desafío-respuesta utilizada en computación para determinar cuándo el usuario es o no humano. El término se empezó a utilizar en el año 2000 por Luis von Ahn, Manuel Blum y Nicholas J. Hopper de la Carnegie Mellon University, y John Langford de IBM.

La típica prueba consiste en que el usuario introduzca un conjunto de caracteres que se muestran en una imagen distorsionada que aparece en pantalla. Se supone que una máquina no es capaz de comprender e introducir la secuencia de forma correcta por lo que solamente el humano podría hacerlo (salvo error).

Como el test es controlado por una máquina en lugar de un humano como en la Prueba de Turing, también se denomina Prueba de Turing Inversa.
A continuación, un vídeo que he preparado donde explico qué es un captcha con más detalle:



Los captcha actuales suponen un problema de accesibilidad para algunas personas discapacitadas, ya que impiden a personas con deficiencias visuales o auditivas acceder a los recursos protegidos por los captcha. El vídeo CAPTCHAs on Social Networking Sites Shut Out Blind Users explica muy bien el problema de los captcha.



El W3C trabaja en resolver este problema y ha publicado el documento Inaccessibility of CAPTCHA donde explica posibles soluciones.

martes, 11 de septiembre de 2007

¿Cuanto sabes de accesibilidad?

He encontrado esta página, Niveles de conocimiento de la Accesibilidad web, en la que se definen 6 + 1 (nivel 0) niveles de conocimiento sobre la accesibilidad en la Web. A continuación incluyo las definiciones:

Conoce tu nivel de conocimiento de la accesibilidad web, una palabra desconocida por muchos pero que cada vez adquiere mayor importancia en Internet. Realice la clasificación de niveles según los conocimientos de accesibilidad web, esa palabra desconocida por muchos pero cada vez adquiere más importancia en Internet.


Esta es mi opinión personal (por lo tanto discutible), y muchas de ellas se desprenden de mis experiencias en el foro de accesibilidad de Foros del Web.

Nivel 0
No me funciona Internet ¿qué hago?:
Estas personas nunca se detienen a pensar sobre la importancia de la accesibilidad web; muchas veces confunden accesibilidad web con accesibilidad a un nivel más general. Por ejemplo, cuando no pueden utilizar Internet por un desperfecto de hardware.


Nivel 1
Optimizado para Internet Explorer y una resolución de 1024 x 768:
Estas personas tienen conocimientos muy básicos de HTML, como para pensar sobre accesibilidad web. No conocen más allá del Internet Explorer, y no conciben que haya diferentes navegadores. Piensan que si una página se ve bien en su computadora, se ve bien en todas.


Nivel 2
Usaré javascript, y el que no lo tenga habilitado que lo habilite:
En este nivel ya se empiezan a escuchar opiniones sobre la accesibilidad web, pero la mayoría piensa que es un capricho de algún loco desquiciado, y que no vale la pena tanto esfuerzo "para eso". La actitud general es "si el usuario no puede visualizar el website, que se arregle como pueda". Los sitios con menús solo en javascript o solo en flash son realizados generalmente por personas en este nivel.


Nivel 3
A mí la accesibilidad no me importa, lo que a mí me interesa es aparecer bien en Google:
En este nivel se produce un primer encuentro obligado con la accesibilidad web, cuando las personas se dan cuenta que la falta de accesibilidad repercute en un perjuicio directo hacia sus sitios.
En este nivel son comunes, a pie de página, los menús solo texto alternativos al menú principal (que sigue estando en flash o javascript). Un acercamiento a la accesibilidad es visto como un "mal menor" necesario para aparecer en los buscadores. La mayoría de los desarrolladores se estanca en este nivel.


Nivel 4
Para ver la versión accesible haz clic aquí:
Las personas en este nivel, ya comienzan a preocuparse un poco, voluntariamente por la accesibilidad, pero aún la siguen viendo como un concepto separado del resto,
sobretodo separado del diseño.
Los sitios desarrollados en este nivel, generalmente no son accesibles pero tienen una versión secundaria desprovista de elementos de diseño, que intenta serlo, aunque muchas veces solo queda en el intento.
Después de todo, recién se están enterando del real significado de "accesibilidad web", muchos han sentido nombrar a las WAI pero pocos saben su significado, mucho menos han leído las directrices de accesibilidad.


Nivel 5
Valido WAI-AAA (Triple A):
Después de leer y ensayar mucho, las personas en este nivel ya tienen un gran dominio sobre la accesibilidad web, y hacen sus webs accesibles porque están convencidas de que es la única forma de avanzar hacia una red más igualitaria.
Sus sitios tienen un marcado HTML semántico, conocen la gran mayoría de los puntos de las WCAG y entre sus lecturas habituales se encuentran temas sobre estándares web, usabilidad y CSS.


Nivel 6
Recientes investigaciones indican que:
Este es el nivel de los "gurus" de la accesibilidad. Son personas proactivas, que no solo aplican la accesibilidad a sus propios sitios, son verdaderos evangelizadores, expandiendo la idea de una web para todos.
Generalmente son miembros de fundaciones como SIDAR, y tienen en su haber libros y artículos publicados sobre lo necesario de realizar webs accesibles y fáciles de usar.

Inspirado por los artículos Niveles de conocimiento de CSS (por Emil Strenstrom) y Niveles de Conocimiento de HTML (por Roger Johansson).


¿Cuál es tu nivel de accesibilidad web?

viernes, 20 de julio de 2007

Guía para crear sitios web accesibles

How to Commission and Design Web Accessible Websites es una guía gratuita elaborada por AbilityNet, el principal fabricante de ayudas técnicas para discapacitados en el Reino Unido, para ICT Hub.

Esta guía contiene los siguientes apartados:
Introduction

Part one: An overview of web accessibility for the VCS
What is web accessibility?
What are the benefits?
Facts and figures
An introduction to accessibility guidelines
Who does it affect?
Future trends in web accessibility

Part two: For commissioners
Introduction
What the law says about web accessibility
Planning for an accessible website
Web Accessibility Policy
Working with designers and developers
Post launch – how to keep your site accessible

Part three: For editors: Writing for the web
Language
Pictures and symbols to help understanding
Writing alternative text
Hypertext links
Headings
Editors checklist

Part four: For developers and designers
Web accessibility in context
Web accessibility level 1 issues
Key Level 2 accessibility issues
Word, PowerPoint and PDFs

Part five: Testing the accessibility of your website
Testing overview
Disabled user testing
Testing for specific accessibility issues
Testing checklist

Part six: Resources
Glossary
Useful websites
W3C Web Content Accessibility Guidelines Checklist levels 1 and 2
Helpful organisations

viernes, 13 de julio de 2007

Metodologías para evaluar la accesibilidad

En la página Metodología, certificaciones y entidades certificadoras de la accesibilidad web en España se recopila una lista de metodologías que se aplican para evaluar la accesibilidad de las páginas web y qué certificaciones y etiquetas (label, sello o marca) hay.

lunes, 9 de julio de 2007

Software para discapacitados

He encontrado esta página sobre el Projecte Fressa donde hay disponible gran cantidad de software para personas con diferentes tipos de discapacidad.