This is my presentation for EUROIA 2009 at Copenhaguen.

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.