When designing complex systems, applications, websites, etc., accessibility issues should be considered before any single line on the paper, not only for governmental and corporate websites, but also for advertising products or intranets. However, accepting the user diversity implies a certain number of constrains and requirements that have to be taken into account when creating our prototypes. This will allow us to save time, money and gain sustainability in our projects.

First of all, we must understand people with disabilities requirements. Two great tools to understand these requirements and look up for solutions are the documents “Web Content Accessibility Guidelines (WCAG 2) 2.0” and “Accessible Rich Internet Applications (WAI-ARIA) 1.0”.

The previous version of WCAG, v 1.0 , was very strict and technology-focused, so many web creators simply rejected to create Rich Internet Applications if they had strong accessibility commitments. Consequently, many accessible websites were not very impressive. As a result accessibility was perceived as a limitation to create eye-catching websites; and advertising sites simply ignored accessibility features. The W3C members involved in the accessibility task force observed this situation, and have updated the WCAG to focus it on content and human capabilities rather than in restricting the technology to use; and started a working group to create a set of recommendations for creating accessible RIA.

Unfortunately, the W3C forgot to make WCAG 2 usable: The quick reference is equivalent to 51 printed pages; the summary is about 41; and imagine the rest of it.

So, my contribution to this conference is to explain the most relevant tricks to comply with accessibility that involves Information Architecture (IA) in the different steps of the process of creating a web site or application.

Let’s see some examples.

Imagine a nice data chart, like a bar graph or line chart, that summarizes the temperatures in Copenhagen. Blind people just will access to the label “figure 1. Temperatures in Copenhagen”, but this will not be information at all for them. Some extra effort needs to be done here by IA. How? There are different options, but the one I like most, as it creates really meaningful information is to add a description on what the chart says: a high-level summary of the data, trends and implications comparable to those available from the chart. Extra ball: provide the actual data in a table, so blind people could access to all the information, as well as some web bots.

On the “About the company” you want to include the shareholders meetings videos. Now blind people can hear what they say if their browser supports that type of video. Neverthelesss, deaf people can’t access to the information, they just watch people arguing, and probably there are not close-up shots to read their mouth. So the IA must include a solution in the prototype and in the planning. My best option is transcribing the video into a separate file, and then including it. Extra ball: apart from the transcription, synchronized subtitles would be really great.

But, what happens if we have a live broadcasting website? How can I make the people who are hearing impaired to watch real-time presentations? WCAG 2 provides several solutions, but all of them imply creating captions for live synchronized media. The good notice is that captions can be generated using a real-time text translation service.

Since our prototypes are (usually) only on black and white, colors are supposed to be a graphic designer issue. But think of a customer that wants to indicate that something is wrong or right through traffic lights, and he wants this information to be implemented in the prototype. Well, you must consider that color-blinded people may not be able to distinguish the red from the green one (there are many combinations of colour blindness, although red-green is the most typical). My option (if the traffic lights are mandatory) is not relying only on color. Add text to your wireframe and put a stick on it explaining why.

Quick links should be available for features or contents that some people might find annoying or disgusting. I am referring, for example, that music that the customer strives to play automatically when entering on the website. Blind people will blame on that music that becomes a noise on their way to listen to their voice-browser/screen reader. Just don’t do it, please.

One of the most difficult issues that information architects and web designers must face is the moment when the user increases the text size, because he has low-vision or uses a small screen. When this happens, if we have not taken preventative measures, boxes usually loss their proportions, horizontal bars appear, contents overlap, and the beauty and balance of the page fail. This is a delicate matter on the homepage. My solution is to add a second version of the page on the prototype with 200% bigger fonts. This way, graphic designers and front-end developers will be aware on how the page should behave when the user enlarges the page. Extra ball: Legibility also rises up when font is big enough; you avoid justified text and provide sufficient inter-line and inter-column spacing, so perhaps your user will not need to re-scale it.

As you can see, there are many different things that we, information architects, can do to create accessible applications or websites. Taking into account them help us to create a better design. The point is, as we are at the start of the chain, the fewer the errors we make, the lower complains our product will have by users with disabilities, by an accessibility auditor or by a techi using the last-hit in 4-G mobiles. Thus, less work will be need to do by information architects, graphic designers, front-end and back-end developers, and in a nutshell, the hole team to repair problems in the desgin found when users evaluations are done at the end of the process.

How Accessibility issues affect Information Architecture

¡Directo a mis favoritos desde ya!
¡Gracias a los dos!

Por un lado está la traducción de las pautas al español, cosa que ya está hecha desde diciembre, pero que no la quieren hacer pública hasta que Sidar, AENOR y otras empresas no las dén el visto bueno . ¿Por qué tanto retraso? ¿A lo mejor porque le interfieren en su negocio de vender la norma UNE139803 (vulgo ‘copia-barata-de-las-wcag1′)?

Por otro lado, tenemos la voluntariosa labor de qweos, pero no deja de ser la traducción de un obsoleto borrador de trabajo de 2004.

Así que, dado que la gente está bastante parada, he decidido mover ficha en este sentido.

• Fase 1: He creado el sitio web One Guideline A Day, donde iré analizando una por una las pautas, criterios de éxito, técnicas y errores comunes que vienen publicados en la WCAG 2, comparándolo con las anteriores y aportando un poquito de mi experiencia en este campo. Está escrito en un inglés con acento de Madrid, así que es fácil de comprender.
• Fase 2: Una vez terminada la fase 1, y si antes no lo han sacado ya, iré traduciendo las WCAG 2 al español. Busco colaboradores voluntarios para ir aligerando/adelantando trabajo. No será ‘la oficial’ pero probablemente sea la más veloz en publicarse tal como funcionan las cosas en el país de ‘vuelva usted mañana’.

Lo normal es que hayan recibido la visita comercial de una de estas empresas o las conozcan por otras referencias, pero no tengan claro cuál es mejor, porque cada una tiene su ventaja diferencial comercial concreta:

• Inteco: “Somos la entidad gubernamental de referencia en este tema”
• Technosite: “Somos del grupo ONCE, llevamos décadas en el campo de la accesibilidad”
• Fundación CTIC: “Somos los representantes del W3C en España, que son quienes han creado las WCAG”
• Aenor: “Somos los que hemos creado la norma UNE, que es la que hay que cumplir”.

Lo malo es que ninguna certificación es la “oficial”, ni siquiera la de la W3C WAI, que cualquiera puede poner en su web la pegatina sin haber mirado nada. Y de las empresas que certifican, ¿quién garantiza que saben de accesibilidad? ¿Están ‘certificadas’ por alguien? ¿Hay una licenciatura específica? Pues no, la baza de la entidad certificadora es su experiencia en el campo, el renombre de la institución y las referencias que pueden aportar otros clientes.

Ante este panorama, es difícil recomendar la contratación de una asesoría pequeña con una buena metodología de trabajo y utilizar el sello (gratuito y universal) de la W3C WAI.

Más sobre entidades que se dedican a ‘certificar’ accesibilidad.

Para ponernos en antecedentes: Cuestiones legales

Por si alguien no se acordaba, el Real Decreto 1494/2007, de 12 de noviembre, decía que todas las páginas de las administraciones públicas deberán cumplir la prioridad 2 de la Norma UNE 139803:2004 a partir del 31 de diciembre de 2008. Además la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información (LISI) ampliaba el ámbito de aplicación a las empresas de especial trascendencia económica, lo que yo entiendo como las “grandes” empresas, no las pymes. Sólo dos días antes salía publicada la Ley 49/2007, de 26 de diciembre, en la que se establecen las infracciones y las sanciones en relación a la discriminación a personas con discapacidad.

Los problemas de unas leyes poco claras

Como ya dije anteriormente, las pautas WCAG de accesibilidad son bastante confusas y no siempre hay un criterio único establecido. Es muy facil argumentar una cosa u otra según nuestra experiencia o conocimiento (ver por ejemplo, el debate sobre los H1 en accesoweb). La norma UNE 139803 es un poco más clara con sus ejemplos, pero aún así, en el día a día, también surgen interpretaciones para muchos gustos. Incluso conozco de gente (incluida yo) que no está de acuerdo al 100% con la metodología UWEM. ¿A quién le hacemos caso?

¿Entonces quién se va a encargar de verificar que los sitios web sean accesibles?

He aquí el punto clave. Cuando se publicó la LORTAD (luego LOPD), se creó la Agencia de Protección de Datos con unas competencias muy claras. Y aparte, alrededor de la protección de datos se crearon diversos negocios que te ayudan a cumplir con la ley.

Sin embargo, en relación a la accesibilidad, no hay una Agencia Estatal. Lo más cercano es el INTECO, pero sin tener esas competencias de auditoría. Aparte de INTECO, hay iniciativas privadas como el CTIC, Technosite, AENOR o Euracert que hacen el servicio de auditoría, pero ¿hasta qué punto contar con sus servicios garantiza el 100% de accesibilidad? Es como si una tienda contrata a un vigilante de Prosegur: no te garantiza que no te vayan a robar, pero por lo menos disuadirá bastante.

¿Quién puede querellarse

Según la norma, las personas con discapacidad, sus familias o las organizaciones en las que se integren. Es decir, que la empresa de la competencia no puede meter a otra en líos.

¿Cómo querellarse ?

Si te quieres meter en juicios contra entidades con sitio web “no accesible”, deberás probar:

• a) Intencionalidad de la persona infractora.
• b) Negligencia de la persona infractora.
• c) Fraude o connivencia.
• d) Incumplimiento de las advertencias previas.
• e) Cifra de negocios o ingresos de la empresa o entidad.
• f) Número de personas afectadas.
• g) Permanencia o transitoriedad de las repercusiones de la infracción.
• h) Reincidencia, por comisión en el término de un año de más de una infracción de la misma naturaleza cuando así haya sido declarado por resolución firme.
• i) La alteración social producida por la realización de conductas discriminatorias y de acoso, la inobservancia o el incumplimiento de las exigencias de accesibilidad y de las exigencias de eliminación de obstáculos y de realizar ajustes razonables.
• j) El beneficio económico que se hubiera generado para la persona autora de la infracción.

para estimar la gravedad del agravio. Lo cual se me antoja un camino no de rosas precisamente.

¿Habrá moratorias?

Esta es una pregunta que se hacen muchos gestores que ven que les ha pillado el toro. Probablemente no la haya (no conozco ningún grupo de trabajo con ese fin en el senado), es una medida injusta e impopular (recordemos que es año de elecciones)

¿Quién pagará la multa?

Según la ley,

La responsabilidad será solidaria cuando sean varios los responsables y no sea posible determinar el grado de participación de cada uno de ellos en la comisión de la infracción.
Serán responsables subsidiarios o solidarios las personas físicas y jurídicas privadas por el incumplimiento de las obligaciones que conlleven el deber de prevenir la infracción administrativa cometida por otros.

por lo que las empresas subcontratadas que desarrollen sitios y las auditoras (CTIC, Technosite…) también pagarían multas si no hacen bien su trabajo.

¿Qué pasa con las WCAG 2?

La legislación española va lenta. De momento centrémonos en cumplir la que hay, que suficiente trabajo nos va a costar.

La accesibilidad a día de hoy

Conozco algunas pocas administraciones y empresas que han hecho y siguen haciendo un gran esfuerzo en rehacer por entero su sitio web por aquello de que no eran accesibles ni de blas. Pero también sé de muchas que no hacen nada ni tienen previsto hacerlo.
No hablo sólo de pequeños sitios que incluso racanean con el hosting y el dominio, sino de gigantescos sitios con presupupuestos formidables en los que meten mano centenas de editores de contenido y que nadie puede estar al 100% detrás de todos ellos para ver si lo que han introducido es accesible o no (De hecho sí es posible pero eso sería otra guerra).
Hablo también de empresas que contratan o subcontratan a maquetadores HTML recién salidos de la academia que ni siquiera han oido hablar de las WCAG o mucho menos del cross-browsing.
O de gerentes de proyectos que, para abaratar costos, “se conforman con que se vea bien en IE7 que es el que tiene el presidente de la compañía” (y cito textual de un gerente de proyecto web en una empresa “de especial trascendencia económica”).

• Canción en mp3 de las WCAG 2
• Letra de la canción de las WCAG 2
• Y de propina la canción de las WCAG 1.0

Pasos

1. Descarga la normativa UNE 139803 (versión 1.0) que he preparado. Descomprímela.
2. Importa el archivo xml en el programa PISTA.
   

   

   

3. Aplica la nueva normativa a los análisis de tus sitios web.

   

   

   

Para la versión 2.0 del archivo le pondremos la correspondencia de la numeración de las pautas con la norma. Si alguien se anima, por favor, que me avise para actualizar el post.

A estas alturas no descubro nada nuevo cuando digo que la norma UNE es exactamente lo mismo que las WCAG 1 pero con el orden y las prioridades cambiadas. Para los revisores de accesibilidad, la vida se complica un poquito, sobre todo por el baile en las prioridades: hay que cumplir con las prioridades 1 y 2 de la norma UNE, la cual no corresponde al 100% con las WCAG. Los cambios que he detectado:

Para ayudarme a aprender los cambios, desarrollé una pequeña herramienta en Excel que comparaba las dos normativas, y que a la larga la he ido utilizando en los diversos cursos y trabajos que he desarrollado. En ella pongo todas las normas de la WCAG y a lado su correspondencia con la UNE. Es similar a lo que podéis encontrar en los anexos de la UNE, pero de forma inteligible y manejable. De esta forma, cuando tienes que evaluar los puntos de prioridad 1 y 2 de la UNE, los puedes identificar rápidamente ordenando por la columna correspondiente de prioridad UNE. Si por el contrario tienes que evaluar según la prioridad 1 y 2 de la WCAG, pues lo mismo pero con la columna de prioridades WCAG.

Espero que os ayude en las revisiones. Si encontráis alguna errata, por favor, decídmelo.

Descargar herramienta Excel de Comparativa de accesibilidad