Designing for accessibility

Why accessibility? What does it mean?

Making web sites accessible means opening them for a wider audience than people with vision and the ability to use the internet with a mouse and a keyboard. This is a natural process in every media, books became printed in large print and braille, TV became captioned. As of start of this year in the US and in the UK it is necessary by law for certain web sites to be accessible.

Accessibility does not mean the end of web design and web development as we know it. It simply means the end of immature use of a new technology. When the web was new, everything that was different was a great success. Rollovers, status bar scrollers, dragable or moving elements, zooming and animation were used widely and, almost most of the time, unnecessarily. These gimmicks are cool, when you see them for the first time, but they don´t add any extra value to the web site. They are products of the design playground, touching the edge of what is possible. These times are over, we should grow up as designers and developers and think "What does make sense" rather than "What can be done"

Building accessible software or web sites generally means one thing: Making allowances for characteristics a person cannot readily change.

If I am blind, I cannot become sighted just because your web site looks great and relies on graphical elements for navigation.
If I am colour blind I might not be able to use the navigation, because it uses two colours that look the same to me for text and background.
If I have bad eyesight I cannot focus on small buttons and miniscule pixel fonts to navigate around the page.
If I am physically unable to use a mouse to navigate through a DHTML dropdown navigation, I cannot do so just to justfy the idea that those save time.

All these above problems have to be tackled by an accessible web site. That is the bad news. The good news is, that not much changes for designers.

Back to navigation

Different kinds of disability

The main audience we have to think about are people with "visual impairment", people that cannot see or can only see badly.

These people use, if they are only slightly visually impaired (think of older people with thick glasses), the biggest font setting of their Operating system/Browser. If their eyesight is even worse, they'll use magnifying software, that magnifies parts of the screen in a special window, allows scrolling there and changing the colours.

If a person is genuinely blind, he or she uses a screen reader. These are tools, that sit on top of a browser and read the web site out to you. This means, that anything that has alternative content, will be available to them. Anything that relies purely on visual impression (images, design elements) without alternative content, is lost. Furthermore screen readers, much like text browsers, ";see"; a web site in a linear way. While we can focus our eyes on parts of a design, a screen reader user will have to go through the page as it is defined in the source code. This means that we need to add skip links to our designs to prevent these users to be forced to read parts of the layout over and over again.

People who are deaf and blind use braille readers. These are machines, that turn the text of a web site into braille that can be read with your fingertips. The same rules about linearity of web sites apply here. Generally one can say if a web site is usable on a text browser, braille readers are catered as well.

Mobility impaired people are not necessarily wheelchair users, but people with a bad hand/eye coordination, no extremities or people with muscular deficiencies. Any of these make it impossible for them to use a mouse. They rely on using the keyboard to navigate through the site by tabbing and using the arrow keys to scroll.

These people also may use keyboard guards (big sheets of plastic with holes in them that prevent you from pressing two keys at the same time), or software like slow keys(automatically discarding double keypresses) or screen keyboards (software that shows a big keyboard on the screen that can be used with an alternative mouse or a switch access). Alternative mice range from foot pedals to really big trackballs and simply simulate the smaller mice. Switch or scanner devices function as an on/off switch that can be set via sucking and puffing on a straw, flexing a muscle or blinking your eyes.

Back to navigation

What does it mean for design

First it means one thing: Learning to let go. Accessible design means you can design much like you had before (except for fixed measurements in certain areas), but you have to deal with the fact that this design can and will be totally wrecked by the user's style settings.

It does not mean that you have to design text only pages with links as big as 20 pixels now, it only means that you must be aware that the visual grid layout you use is not a rule of how people will navigate through your site.

It also means that this grid layout needs to a be a lot more flexible to allow resizing of fonts.

Horizontally you can fix the grid, content will just break into two lines if the font gets too big (take that into consideration when designing the navigation), vertically you shouldn't put any constraints on the design. Elements will be as high as their textual content is, not as high as they are in Illustrator.

Some new elements have to be in the layout of an accessible page: ";Skip Navigation"; links and an ";accessibility policy"; link.

Back to navigation

Making images accessible

One of the basic principles the Accessibility guidelines[1] state is that every image has to have a textual equivalent. This does not mean that every picture must have a caption, it means that the HTML developer has to add some attributes to each image:

An ALT attribute, this will be displayed when the browser used does not support images, or due to a slow connection, or a bad link, the image does not get loaded properly. Sadly enough IE, being the most used browser, does display this text as a tooltip popup when you hover your mouse over the image. This is not at all what that attribute was meant to do. The alt text should tell what the image is, in short terms. An example would be "Netdecisions logo". This attribute is mandatory!
A TITLE attribute. This attribute is displayed as a tooltip (Netscape 4.x does not support it though). This attribute should be used for more detailed information about the image, like "Netdecisions, ... we provide yadda dadda yadda". There is no limitation to the length of the text, but generally it shouldn't be longer than 1024 characters. This attribute can be used and helps people with screen readers to envision the image a lot better.
A LONGDESC attribute. This attribute should be used when there is a lot of data displayed in the image, like in a pie chart, or any other mean of displaying data visually. LONGDESC links to an external HTML file, which can contain text in any length you like. The problem with LONGDESC is that not many browsers support it, that is why, for the intermediate time, a lot of web developers came up with a hack. They add a link called "[D]" after each image which links to the same long description document. This is good thinking, but an eyesore for sighted users and a hack to come up with a solution for lacking support in browsers. It is not a necessity and a lot of accessibility experts don´t like it much.

Now, what does this mean for you as designers? Actually not much, but as a visual person and the designer you should be able to provide the HTML scripters with the textual equivalents of the images used. Otherwise he or she might come up with their own...

When writing alternative content make sure to try to think like a blind person. Blind people are not oblivious to moods, they like to hear about things, sighted people take for granted. So, when you use an image that is there to set a mood, by all means write a text that sparks the same mental image.

When creating alternative texts, only do so for images that are there to convey a message, simple border images, rounded corners and spacer blanks should not get an alternative text, a blank ALT tag ensures that the images are valid as to the requirements and are not read out to a screen reader.

The same applies to images that are cut up into different tiles, only write an ALT and a very descriptive TITLE for the first tile, and leave the others empty. This is not the case when different tiles link to different pages.

All these options also apply to animated images, there should be an alternative description describing the meaning of the animation, not a decription of each frame. However, some strict accessibility guidelines do not allow animation at all. The american Section508 guidelines for example require non-animated content for each animated section of the page.

Another thing to avoid is to use graphical elements that could cause flickering while scrolling. This applies to scanline effects, or really small grids.

Back to navigation

Colour issues

One thing the accessibility guidelines[1] are strict about is that you cannot use colour as the only mean of seperating different page elements from another. This means you cannot:

Use red text as a warning without calling it a warning.
Use different coloured buttons or icons in a navigation without explaining what they are.
Set the highlight of a navigation simply by changing its colour. You'll also need to change the font to bold or add an (accessible) image.

Furthermore you need to be sure that different page elements and their backgrounds don´t blur into another. This actually means that you need to ensure a high contrast between foreground and background. A very basic test to provide that is to look at the same picture in greyscale mode.

This test does not ensure that your design is accessible though. The next group of people, we have to think about here, is people with a vision problem called colourblindness.

Colourblind people see the world different than we do, they cannot tell several colours from another, you'll have to avoid those or ensure that there is a very distinct seperator between them. Troublemakers number one are red and green. These are seen as the same grey. Then again, they are an eyesore together for sighted people as well.

Don´t set red on black or black on red. Red appears dark to some colourblind people, which means that the contrast is too low.
Don´t set green on red or red on green. These are complementary colours and will sizzle onscreen even to the eyes of a colour-normal person; most colour-vision-deficient people confuse them.
Don´t mix beige/yellow/orange with red and green.

This is very complex topic, please refer to the links section below for more information about it.

Back to navigation

Layout issues

One problem with layouts these days is that browsers are still quite bad in implementing layout definitions in stylesheets properly. Another problem is, that people are reluctant to upgrade their browsers. Add the differences in operating systems, to that, and that's were we are.

Most complex layouts these days are created with tables, which is a hack that has become a standard. From a semantic point of view, a table is a construct indicating a relationship between its headers and the content.

Humans	Animals
Joe	Rover
Rebecca	Mittens
Tim	Goldie

However, due to the browser industry focusing on Powerpoint-ish presentation effects rather than logical markup rendering and CSS support, we use tables for creating layout.

This is not necessarily flawed, but it means that the order of elements in the page is defined in the HTML markup rather than the stylesheet.

For example a simple HTML page might look like this.

Header
Left navigation	Content	Right extras
Footer

For a sighted person, this is logical and no problem, a person with a screenreader or a text browser, on the other hand, experiences this page as follows:

Header

Left Navigation

Content

Right extras

Footer

Now, imagine the left navigation being 20 links, you'll have to hear and skip through them every time when you load a page of this site.

There is a HTML trick to avoid this, but generally CSS layouts are a lot more flexible in this respect. By using CSS, the order in the HTML syntax can be altered, showing the content first and then the rest, which makes it a lot easier for screenreader users. If that cannot be done, due to the layout being too complex, we need to use "skip navigation" links.

However, CSS only layouts have some problems, it is very hard to create a column layout with background colours.

Header
Left navigation	Content	Right extras
Footer

Is a layout that is very easy to do with a table but almost impossible cross-browser in CSS. Most clean CSS solutions will look like this:

Header
Left navigation	Content	Right extras
Footer

It is possible finding solutions for that, but most are not reliable.

Any layout depending on different columns being displayed next to another with the same height and different backgrounds, is a tricky one. If possible, these should be avoided.

Back to navigation

Data tables

Data tables, as mentioned above, are "real" tables with a relationship between the headers and the content. They are great for sighted users, but for screenreaders, they need a lot of HTML work. For example:

Today's action plan:
Time	Planned Task	Preferred Task	What I actually did
10 - 12	Catch up on replying to my emails.	Have a lie in.	Surfed aimlessly.
12-1	Have Lunch.	Have Lunch.	Had Breakfast.
1-5	Finish that project.	Go to video store.	Caught up on my emails.

Is perfectly understandable to sighted users. A screenreader reads it out to you like this:

Time Planned Task Preferred Task What I actually did
10 - 12 Catch up on replying to my emails. Have a lie in. Surfed aimlessly.
12-1 Have Lunch. Have Lunch. Had Breakfast.
1-5 Finish that project. Go to video store. Caught up on my emails.

This example is an excerpt from an article about this subject on evolt.

The logical connection of the cells and the headers is not given anymore. This can be rectified in HTML, but it becomes increasingly complex when there is more than one level of logical connection. Try to avoid tables requiring this, like this example:

CSS	Browsers				Operating systems
	Phoenix		IE		Mac		PC
	1.0	1.2	5.0	6.0	Os9	OsX	98	2000
:hover		x		x		x		x
:active		x	x			x		x

This is overly complex, and the empty cells do not make sense for any non-sighted user. There has to be another solution.

Back to navigation

Navigation

Accessible navigation is no rocket science, the best practises are:

Avoid graphical navigation, as people with bad eyesight and no screen magnifier cannot resize the copy and make it readable for them.
Use CSS and textlinks whenever possible, as nowaday's computer systems have inbuilt antialiasing of screen fonts; they look smooth enough.
Allow enough space for the navigation to wrap to two lines if necessary.
Navigation must not rely on any plugin, or scripting language. If it relies on, for example flash, make sure to display an alternative at the same space on the screen (the old excuse "but there are textlinks on the bottom of the page" does not work too well in court).
Define a colour for each state a link can have: normal, active, hover, visited. This is necessary to avoid the user's browser setting rendering links unreadable.
Make sure to define the alt and title wording for image maps.
Ensure that the navigational parts of the page are clearly distinguishable from the rest of the page, it's a nightmare for normal users to try to find the navigation, even more so for handicapped.
Ensure that the navigation does not require a mouse to work. This applies to dropdown menues especially.

One special arrangement we have to work with when we want to make pages accessible, is that large parts of navigation can be skipped with a link. To do this you add a "Skip navigation" link before the list of links. Clicking, or activating this link (via keyboard or switch) will allow non-visual and mobility impaired users to jump directly to the content rather than clicking through each and every link. These links have to be visible. They are the only visible change we have to live with.

Back to navigation

Text sectioning - Headlines and Paragraphs

As screen readers allow users not only to jump from link to link via keyboard controls, but also from headline to headline, text elements of pages have to be logically structured. In HTML this means using headline tags, instead of styled divs, and paragraphs instead of linebreaks.

For designers, this does not mean much difference, only that texts should be logically ordered in headlines, subheadlines and paragraphs.

If possible, avoid headlines being graphics, they can be made accessible, but the tabbing option for screenreaders is hardly possible.

Back to navigation

Percentages vs. Pixels

To make accessibility easy, the best a designer can do is forget about the myth of pixels being a good way of defining sizes on a web site.

Newer browsers allow applying own stylesheets to a web site, meaning the carefully thought of design grid can be wrecked completely and the site become non-usable for the person sitting in front of the browser.

This is not pure hostility of the user, he (or she) might just not be able to read the size of text you defined. As screen magnifiers are yet programs that you need to install (Opera is the only Browser on PC scaling the whole web site, images and copy), only people with severe sight problems will use them. Users with a bad but not severe sight impairment might be lucky enough to know, or know someone who knows, where to find the accessibility option in newer operating systems, but we cannot rely on that.

The normal way someone tries to make a page more readable is to resize the font size of the browser. When the font is defined in pixels, this does not help.

Real accessibility fanatics apply a tool to the page, that allows the user to resize the font and store his settings in a cookie or a database. This is fun to do and a very nice extra, but we are here to create websites, not code around browser problems.

It is OK to define any horizontal space in pixels, unless we want pages to allow to use the whole (or the really small) space the users browser shows. However, vertically, text should have space to spread out. Any font resizing means the text needs more space on the screen, if there is vertical space, the text will wrap, if not, the whole layout will fall apart.

Back to navigation

Forms

Making forms accessible requires the following:

Each form element needs a label defining it. This is normally a text next to it. For a designer, there is no extra work, but the HTML scripter needs to add another tag.
Try to avoid images as buttons, submit buttons should stay submit buttons, rendering the way the browser is set up and resizing with the font-setting.
Forms must be usable without scripting support, this means that every change in the form requires sending the data back to the server. Combo boxes changing values of other elements when you change them cannot be used by keyboard and switch access users. Therefore, each form needs one distinct submit button. Javascript cannot be used.
Styles applied to form elements (for changing the look of scrollbars and text in a textarea for example) cannot be taken for granted. The textarea might become unusable on smaller screens with big font setting.

Back to navigation

Multimedia

Bottom line accessibility for multimedia is:

Provide a textual equivalent of the content (transscript of speeches, videos)
Use the accessibility options in flash.

Other than that, all the colour and animation restrictions of images and texts apply here aswell.

Back to navigation

Accessibility policies

Every accessible page needs a prominent link to its accessibility policy. This is a legal text much like the privacy police or the terms of use. In it you define which level of accessibility your site has, and also give information about the accessibility tools, that are in place. These tools include the settings for accesskeys and if applicable the tab order and any server side font changing utility.

Back to navigation