Accessibility Considerations

By now you've probably heard of the American Section 508 law that covers accessibility in government-funded web sites. You may well have also heard about the cases of the Australian Olympic Committee web site that was the subject of a lawsuit. But what of intranets? Are they covered by the scope of such Acts as Section 508 (http://www.section508.gov) and the UK Disability Discrimination Act 2004 (http://www.hmso.gov.uk/acts/acts1995/1995050.htm)? Well, an intranet is technically a web site so the answer should be "yes". However, we need to think about exactly who is using the site. Is it a member of the public or someone else?

In terms of a pure intranet, the users will be our staff. The provision of the "usual" disabled facilities such as toilets and wheelchair ramps are the obvious things that companies do for disabled staff. But what about their intranet? In the UK at least, an intranet could be classed as a workplace arrangement, which means that if an employee who is disabled cannot do their job because the site is inaccessible, this could create a case where an employer would be obliged to make a "reasonable adjustment".

Note

Putting in alt text for every image doesn't take that much time if you do it as you go along. Having to revisit your entire site, page by page, to put in the alt text that you didn't do the first time around could take a colossal amount of time and money.

Interestingly, in the UK at least, although the 1995 Disability Discrimination Act covers any company that employs more than 15 people, in its "What Employers need To Know" document (which can be downloaded from http://www.drcgb.org/drc/lnformationAndLegislation/Page313.asp) it states that companies don't have to start making adjustments until after they have employed someone with disabilities. However, as with many such issues, it is better to have them in place from the start, than have to spend a long time retrofitting a site.

There are many countries that either have legislation regarding accessibility or are soon to be introducing it. Anyone that develops for an intranet should seriously consider making their pages accessible. Cases involving accessibility legislation are still in their infancy and therefore attract global publicity, which is something that your company will want to avoid. Even if you currently don't employ anyone who has a disability that would prevent them from using your intranet, you probably will do at some point in the future. Starting with the attitude that your intranet should be accessible to all will stand you in good stead for the future.

The Web Accessibility Initiative

In 1999 the W3C introduced the Web Accessibility Initiative (WAI) and its related Web Content Accessibility Guidelines (WCAG) (http://www.w3c.org/wai). This is a set of rules and guidelines that show web developers how to create pages that are accessible to people with disabilities. It is these guidelines that are becoming the de facto rules against which all sites are deemed accessible. Levels of conformance are divided into three separate levels: A, AA, and AAA (with A being the lowest). The WAI also publishes a series of checkpoints against which to audit your site. There are numerous organizations that you can hire to audit your site but the majority of them will be working against the WAI, so you can save your company some money and do it yourself!

Auditing your own site is a fairly simple if slightly time-consuming task (although one that should be considered essential). The first step is to print off a copy of the WCAG checkpoints that can be found here: http://www.w3.org/TR/WCAG10/full-checklist.html. There are online tools such as the Bobby (http://bobby.watchfire.com/bobby) and Site Valet (http://valet.webthing.com) that are very useful for checking the accessibility of your pages, and will be useful at the auditing stage.

What you then have to do is to systematically examine each checkpoint and mark your intranet against each one. Each checkpoint is listed with its own reference number which can be clicked on and which will take you to the relevant part of the full WAI standard. From there you can follow links to look at techniques for achieving the standard. When auditing yourself you have to be ruthless; there is no point in saying "oh well, we're sort of there, I'll mark that as a Yes" if in reality you've failed or only partially passed the checkpoint. Should the worst come to the worst and you end up in a court of law, you'll only have yourself to blame.

Depending on the size of your site and how well you know it, self-auditing could take between an afternoon and about two days. A best practice after that would be to fully write up your findings and then go about planning to change things. Again, if the worst did come to the worst but you have proof that you are aware of your site's failings but you were actively working towards accessibility, this could potentially help your case.

Plugins and Specifics of the WAI

The W3C, through its Conformance and Quality Assurance program (http://www.w3.org/QA/2002/07/WebAgency-Requirements) is telling developers to use PNGs for all raster images and SVG for every other type of image.

The use of PNGs on an intranet is an example of the WAI's "use W3C technologies when they are available and appropriate for a task and use the latest versions when supported". This would mean using PNGs for all bitmap images instead of GIFs or JPGs and the use of SVG, MathML, and other XML-related technologies in their rightful places. Herein lies a problem. If we look at the PNG as a graphic format, there is no doubt that it offers much more than both GIFs and JPGs - it can have varying degrees of transparency, can happily deal with large areas of flat color and also more complex images and photographs. But, if we want to natively view a MNG (an animated PNG) without the use of a plugin, unless we're running Netscape 6+ or Mozilla 1+, we can forget about it!

"Realistically, however, we're going to be using GIFs and JPGs for some time."

The problem lies with browser support. Netscape 7 and Mozilla 1.1 both have excellent support for the PNG format, but unfortunately IE6 does not. Bearing in mind that many intranets will be based around IE, in the world of complete standards support we have a problem. Realistically, however, we're going to be using GIFs and JPGs for some time.

We have the same mixture of benefits and problems with the XML-based language SVG. Images created in SVG can be made accessible, they can be zoomed into and panned around using a mouse and keyboard, which gives them a massive edge. Because an SVG file is just text (you can right-click and view source just as you can on any normal web page) you can improve accessibility by adding textual descriptions of the image using the <desc> element. Text in SVG images is real text that can be copied and pasted into other applications such as Word which could never happen with a bitmap image. For more information on the accessibility features of SVG, see: http://www.w3.org/TR/SVG-access/#What. However, at present, SVG requires a viewer to be able to work in a browser. This can be downloaded from http://www.adobe.com/svg/viewer/install/main.html. This is all well and good for the individual user who can download and install it, but what about distribution across a network or intranets?

As we have mentioned earlier, many things determine the pace of change within a corporate environment and an intranet most likely won't be at the top of the list. So what can we do? Well, if we want to present technical data as images (for example a pie chart of last month's sales figures) we can use a bitmap image and use the HTML <longdesc> element to provide a link to a page that has a plain-text description of that image.

If you are using Dreamweaver MX as your development tool, it comes with several accessibility options that can be turned on via Edit > Preferences > Accessibility. Turning on Form Objects, Frames, Media, Images, and Tables will make Dreamweaver prompt you for the required accessibility options when inserting an object. For example when you place an image on a page it will prompt you for an alt attribute and also the URL of any <longdesc> page you might have set up.

This is a very brief overview of a massive topic. For more information on Accessibility and web sites, read Constructing Accessible Web Sites (Jim Thatcher et al., glasshaus ISBN 1-904151-00-0).