Accessibility Guidelines

Many developers are aware of the need to code for cross-browser tolerance (making sure that pages are functionally equivalent in Netscape 4.7 on PC or IE5.5 on Mac) and of the principle of graceful degradation (users of older browsers get as rich an experience as is possible given platform constraints; users of earlier technologies get full content but may lose 'added value' or 'bells and whistles'); but ensuring full accessibility goes beyond this to consider users who need to access our information with non-graphical interfaces or no visual interface whatsoever.

Many Internet users with disabilities find websites difficult or even impossible to use simply because of the way they are designed. We are working hard to make our site compatible with various types of adaptive technology used by people with disabilities, such as screen readers.

Whilst web editors should be aware of the WAI guidelines(Web Accessibility Initiative) released by the World Wide Web Consortium. these are just best practice guidelines, and are not yet a legal requirement. Recent legal cases , however, have shown that this is changing and the university now demands a strict adherence to the minimum guidelines. This is not as difficult as you may think.

Application of the following guidelines to your pages will ensure, in so far as it is possible, their accessibility to as wide an audience as possible.

Accessibility Checklist

All sites MUST meet the following requirements.

• Provide alternative ALT text for every non-text element on a web page; including images, imagemaps, audio, video and any multimedia.
• Ensure that all information conveyed with colour is also available without colour.
• Ensure that there is sufficient contrast between text and background colours. Consider not only users with standard colour vision, but those with colour blindness.
• If possible avoid scrolling text and other dynamic content which may be hard to read. Where necessary provide text alternatives and keep these up to date when dynamic content changes.
• Avoid any technique which may produce flickering effects on-screen.
• Use the clearest and simplest language for site content. We will be releasing a style guide for content and writing.
• Minimise the use of server-side Image map regions.
• Ensure the use of ALT text when using client-side image maps.
• Tables containing data should contain clear row and column headers.
• Do not use frames.
• Check our Multimedia guidelines. At present we do not recommend the use of Java applets or plug-ins for navigable elements. Your site should still be navigable if plug-ins are not supported.
• Stylesheets are an excellent method of maintaining a consistent format and layout. Many disabled users may use tools which rely on an alternative stylesheets, so where they are used, web pages should also be readable without them. Turn the stylesheet off and check your pages. (Opera 7 is an excellent tool for testing alternative stylesheets.)

Please note that Macromedia Flash and Adobe Acrobat (PDF) formats are NOT accessible formats, unless specific steps are taken during their construction. Please contact the webteam to find out more about this.

For more information about web accessibility or the SENDA guidelines please contact the webteam or

ALT text

All images must use the ALT attribute of the IMG tag to adequately describe the content or function of the element.

e.g. <IMG SRC="home.gif" ALT="Return to the university homepage">

Please ensure that the ALT attribute is the text equivalent of the image, and not simply descriptive

e.g. ALT = "a button" is not particularly helpful.

You can include punctuation in ALT attributes to improve comprehension.

ALT text for Spacer GIFs

There are two exceptions to this rule: so called 'spacer gifs' (invisible images used by designers to hold table cells open in complex layouts that would otherwise collapse on certain browsers) should not be given ALT text as this will simply increase the confusion for those who cannot see the design in the first place. ALT="" is best used under these circumstances.

ALT text for Graphical bullets

The second exception relates to images used as graphical bullets. In this instance use ALT="*"

General Points

• There should be a text equivalent or a specific accessibility guide for all non-html files (eg powerpoint, PDF etc). Adobe's accessibility service at http://access.adobe.com can reformat PDFs to HTML or text files.
  
• Provide captioning and transcripts of audio presentations, and descriptions for video. If at all possible provide alternative information sources. Vital information should never be presented solely in the form of multimedia.
  
• Always provide alternative content to scripts, applets and plug-ins in case active features are inaccessible or unsupported - assuming of course that such features have been deployed out of necessity. If not, consider if you need to use them at all.
  

• If you must use image maps, use client-side image maps in preference to server-sidemaps. , and don't forget to add ALT attributes to identify the hotspots.

  <MAP NAME="navigation image map">
           <AREA SHAPE="circle" COORDS="70,70,35" ALT="Open Day information">
  </MAP> 

Validating your HTML

• Use standard HTML structural elements to indicate the informational hierarchy within your document. By this we mean utilise <H> tags to indicate section headings rather than plain text surrounded by FONT tags to make it look bigger.
• Similarly use OL or UL in conjunction with LI to create lists instead of re-inventing the technique for yourself with BRs, asterisks and full-stops. Ideally - if you know what you're doing - ensure graceful degradation by applying Cascading Style Sheets (CSS) to standard HTML elements.
• Under no circumstances deploy text that flickers or blinks on your site - not only is this an offence against taste and decency, it's also a contravention of JANET acceptable use policy.
• Ensure that your page displays properly when the font size is increased in the browser. Check your web pages at 640x480 resolution - horizontal scrolling should not be necessary.
• Use META DATA to ensure an efficient, concise result for your page when returned by a search.
• If you are using forms, ensure the layout is simple and logical (for example, position input elements and their labels side-by-side).

Frames

Frames can cause severe navigational difficulties particularly for blind users who find the navigation between frames particularly problematic (this is in addition to the usual problems of not being able to bookmark framed pages and their exclusion from search engines - or the possibility of bouncing into part of the frameset and losing the navigation entirely). Consequently, do not employ frames on a site unless:

• You can justify their functional necessity to the satisfaction of the university webteam.
  
• You provide NOFRAMES content, in excess of the standard "You require a frames-enabled browser to view this site"
  
• Each frame must have an appropriate title - ie first frame=navigation, second frame=content etc. Each page must have a title.
  
• The entire ensemble functions in a technically exemplary manner, with all external links 'breaking' the frameset and all internal links sitting happily where they are supposed to (and not 'nesting').

Tables

• When using tables to display information (rather than simply for layout purposes), ensure that a horizontal cell-by-cell reading will make sense, as accessibility software "linearises" tables.
• Try to use <TH> in preference to <TD> tags in order to highlight table headings.
• Use sensible colour contrast on your site. Visually impaired users, including the colour-blind, may find certain colour combinations of background and text difficult to read; certainly avoid red/green combinations at all costs. One way to check adequate contrast levels is to take a screen shot of your page, render it in greyscale mode and see how easy it is to read everything.