We really wanted to demonstrate through our web presence that a site could be both visually appealing and accessible.
We wanted to show that flash could be used on a site without making it inaccessible. We wanted to show that a content management system could ensure a site remains accessible even when used by people with no coding knowledge. Finally, we wanted to make the world a happier, more loving place!
Did we achieve all of this, probably not!
The trouble is that most web designers agree web accessibility is important but few can agree on the best way of making a site accessible. That is mainly because it is still an evolving area and new ways to improve accessibility are being found all the time. As of now, we believe that the techniques used on this site are some of the best but no doubt, this will be out of date in a matter of weeks!
So what is the approach we have adopted?
A quick word on flash before we move on to things that are more important. Some hard line accessibility zealots will no doubt disapprove of our use of flash on this site. However, we believe that if used correctly flash and accessibility can sit comfortably side by side. Whenever we have used flash we have ensure it is accompanied by a clearly marked description and alternative ways of accessing the same information it provides.
If you are bothering to read this page, you have probably already heard of the WAI guidelines which layout three levels of accessibility. This site has been designed to be level three compliant (the highest level), with one notable exception.
Checkpoint 3.4 states:
Use relative rather than absolute units in markup language attribute values and stylesheet property values.
In short, this means that everything should be scalable. That includes fonts and layout. Although in our default style, we have made the body text scalable, the rest of the interface is not. It was our feeling that, after experimenting with both scalable and elastic sites, complying with this checkpoint would undermine the design. This would jeopardise our first objective, which was to show sites could be both accessible AND visually appealing. Obviously, this decision is a subjective one, but it should not be interpreted as a lack of commitment to people with a visual impairment and who require the ability to resize text. We have just chosen to solve the problem in another way (see below).
Low vision version
Because we have largely conformed with the WAI guidelines and built the site using web standards we are hopefully that users of speech browsers will not encounter any serious problems. Of course, you can make no guarantees as speech browser have more options than you can shake a stick at, and it is possible one of these will screw up the site.
However, there is a much larger group of visually impaired people, which do not use speech browsers, but do require an enhanced interface. One option is to make all the fonts on your site resizable as explained above, but this fails to tackle some of the other issues faced by visually impaired users. We have therefore introduced a low vision style for the site that is designed specifically to meet these users’ needs without compromising the default user interface.
No doubt some of you reading this page are thinking; "but hang on, doesn’t this fly in the face of RNIB policy on web accessibility?" This refers to a statement on the RNIB site that says:
At RNIB, we recommend against providing a text only version as much as possible, simply because being treated differently can reinforce the feeling of marginalisation that someone with a disability experiences.
However, we are not talking about a separate text only version of the site that quickly becomes out of date because it is poorly maintained. What we have done is create a secondary interface to the same content designed specifically for a visually impaired audience. They are accessing exactly the same content, simply displayed in a way that suits them.