Guidelines for Building an Accessible Web Site

Introduction

This document explains and discusses the rationale and technical requirements for making information published on the World Wide Web available to as wide an audience as possible. A set of guidelines is developed - which if followed - should help any organisation increase the potential audience who can access their information and services. Creating an accessible Web site is not a science - there is no one 'right' way to do it. There are numerous sets of guidelines to be found on the internet outlining what constitutes an inaccessible web site, what characterises an accessible web site and how to get from the former to the latter.

Having said that, there does now seem to be a growing consensus as to what the most important features of an accessible Web site are - and some guidelines explain these better and are more comprehensive than others. Possibly the most complete set of guidelines are those created by the World Web Consortiums (W3c) Web Accessibility Initiative at: http://www.w3.org/WAI/. These guidelines have been developed over a number of years and have been the outcome of collaboration between Industry, accessibility research centres, government and disability organisations.

About the World Wide Web Consortium [W3C]

The World Wide Web Consortium is the recognised standards organisation of the World Wide Web. It is a Consortium led by Tim Berners-Lee, Director and creator of the World Wide Web, and Jean-François Abramatic the Chairman. It is funded by Member organizations. It is vendor neutral, working with the global community to produce specifications and reference software that is made freely available throughout the world. To date, 390 organizations are Members of the Consortium. For more information see http://www.w3.org/

The Web Accessibility Intitiative Guideline developed by the World Wide Web Consortium (W3c) are comprehensive, long and extremely detailed - they are also at times quite difficult for the non-technically inclined person to understand. As well as sharing my own experiences of creating accessible Web sites - I will be using and referring to the W3c guidelines frequently, in such a way that I hope makes the material usable and easier to understand.

The guidance provided in this document should be considered as an introduction to creating an accessible Web site rather than an exhaustive review of the topic - which could easily fill a large and heavy book. More information including the full guidelines and technical reference documents can be found on the World Wide Web Consortiums Web Accessibility initiative pages (http://www.w3.org/WAI/) and the many other resources both on and off-line. A list of useful Web sites will be provided at the end of this document.

There is no average information consumer

At the heart of the idea of accessibility on the internet is the notion that there is no 'standardised information consumer 'and no standardised device being used to access the information to be found on the internet i.e. everyone is not using the same type of computer, the same type of browser or can be assumed to have the same physical or sensory abilities. Variety is the in fact the 'order of the day' and the devices and ways people use to access that World Wide Web are many and varied.

An example would be a person who cannot see and is using a text only browsers with a refreshable braille display or audio screen reader. Others will not be using a mouse or will be using an early version of a browser, others again may be using a 'Personal Digital Assistant' (PDA) such as a Palm Pilot, or they may be using a mobile phone to download their e-mail and view the web.

Designing an accessible web site is not just about making sure disabled people can access your information - which of course is important - it is about making sure everyone with there favourite Internet enabled device can access and use your information (see http://devices.internet.com/). The aim is to build a site that is flexible enough to be adapted to the needs of the user.

Often organisations explain to me they have made the text on their Web pages large because they want to ensure that they are accessible - i.e they want to make sure that visually impaired people can read them. This - though well intentioned - is the wrong approach. Consider the following quote from the The Royal National Institute for the Blind (RNIB) Web site ( http://www.rnib.org.uk):

Some people prefer large text, while others can only read smaller text. Most people need a highly contrasting colour scheme, while others can only read yellow text on a black background. To cater for everyone, Web sites should be flexible in design, enabling the individual to adjust the text and colour settings to suit their needs. (RNIB http://www.rnib.org.uk/wedo/research/hints.htm)

It is not about trying to 'hard-wire' in accessibility - extra big text might make your page easier to use for a small group of people but it is likely to make it even harder to acccess for many others. The only way to 'hard-wire' in accessibility is to code your pages with standard compliant HTML and not to get in the way of a user who would like to alter the size, colour and layout of the page to suite their own needs.

It seems to be a little know fact - but it is worth remembering - that almost all Web browsers allow the text size, colour and background colour of Web pages to be changed. Try experimenting with the setting in your own browser. Check how your pages look with much larger or smaller text - and even more importantly, check if the design of your page allow these attributes to be altered at all. If they can't be altered ( i.e the designer has tried to force the page to look the same on everybody's screen) then this should alert you to the fact that your pages are not as accessible as they could be.

Another erronious belief I hear again and again is that accessible pages need to be just text - and therefore have to be fairly boring and plain. Let me set the record straight right here - that is absolute rubbish!

Creating an accessible web site does not mean you cannot use images, video, sound, animation etc - rather it is about making this multimedia content accessible to as wide an audience as possible. So if you have a photograph provide alternative text explaining what the photograph shows, if you have video or audio provide captions or a text transcript. In other words provide alternative ways to access the same information.

Why do we need an accessible Web

In two years time it is estimated that 25% of all Western European households will be connected to the Internet and by 2004 almost two thirds of businesses in Europe will have Internet access ( DataMonitor). At the same time as it is growing at an alarming rate the Internet is becoming a mainly graphical and highly ‘design’ oriented medium. This has implications for many of the 5 million disabled people in the UK; in the new ‘digital economy’ many disabled people may be excluded. Attention must be paid to the problems of accessibility on the World Wide Web and other Internet based technologies. The Internet is, and will be used, by local and national government, banks, educational establishments, shops, information providers and indeed in every concievable area of life to deliver information and services .

Currently almost 75% of all Web site traffic is images². Multi-media rich sites are inaccessible to many disabled people; e.g. a blind or visually impaired individual who use a speech synthesiser cannot make sense of information on the World Wide Web when it is purely graphics based.

The Internet still has the potential to break down many barriers; you don’t have to be able to hear to use E-mail, the Web or Usenet; Web pages or e-mail can be made to talk and a physical impairment need not be a barrier to navigating through the rich source of information to be found on the World Wide Web. However there are aproximately 1.7 million individuls in the UK who are unable to read standard print with ease, 17 million adults with literacy problems and 1 million people with learning difficulties (Informability manual Central Office of Information; Gregory, Wendy 1996 HMSO ISBN 0117020389). The move towards the World Wide Web which is not text based will have an impact on a significant number of these people.

If we are not to end up with a substantial percentage of the countries’ talent being excluded from full participation in the coming ‘digital economy’ we have to highlight and address these issues.

Pressures for Change

As we move towards the 'digital economy', banking, education, communication, shopping and governance will increasingly use, and rely on, the Internet and it's variants. Accessible information and particularly accessible Internet based information is vital for social inclusion and full citizenship for many disabled people. For more on why making the Web accessible is important refer to my short article The Internet and Disabled People - Access Denied? (http://www.ispn.gcal.ac.uk/accsites/whysumry.html)

In terms of making sure the information you are producing is accessible, organisations - particularly organisations in the public sector - should be aware of the following 'pressures for change':

The Disability Discrimination Act (http://www.disability.gov.uk/dda/index.html and http//www.hmso.gov.uk/acts/acts1995/19950550.htm)

Other relevant Legislation Local authorities and health boards have in recent years been required by legislation to provide information about their services to certain categories of people, including disabled people. They must also provide information about other relevant services of which they are aware. The National Assistance Act 1948, Chronically Sick and Disabled Persons (Scotland) Act 1972, The Disabled Persons (Services, Consultation and Representation) Act 1986, National Health Service and Community Care Act 1990

"Disability Rights Commission" which is now up and running and has a Web site at: http://www.drc-gb.org/drc/default.asp The aim is to eliminate discrimination against disabled people and "take appropriate steps with a view to encouraging good practice in the treatment of disabled persons."

Guidelines for Government Web sites ( http://www.iagchampions.gov.uk/Guidelines/websites/default.asp) These guidelines are sparse but should be looked at. From the Guidelines, "Sites which comply with the guidelines will be rich in authoritative content, well designed, linked to other sites with relevant government information and accessible by a very wide audience. "

The Scottish Accessible Information Forum (SAIF) (http://www.connections.gcal.ac.uk/saif/) Set up to take forward the recommendations made by the Scottish Working Group on information Services for Disabled People and Carers in it's final report Enabling Information (1995). (http://www.connections.gcal.ac.uk/saif/EnablRpt/Intro.html) Recently published the SAIF Standards for Disability Information and Advice Provision in Scotland: http://www.connections.gcal.ac.uk/saif/standrds/Index.html.

The emergence of the social model of disability and disability led organisations.

Citizen's Charter initiative Launched in 1991 to make public services more answerable to consumers. The right to comprehensive and accurate information about services is an important element of the Citizen's Charter. As part of the Citizen's Charter initiative the Central Office of Information produced The Informability Guide in 1994 to promote good practice in ensuring that information is accessible to as wide an audience as possible, including people with literacy problems, sensory impairment or learning difficulties. The government also published in 1994 The Citizen's Charter and People with Disabilities, a checklist, to be used together with the Informability Guide.

The Governments Social Exclusion Unit and the Scottish Social Exclusion Network (http://www.scotland.gov.uk/inclusion/default.htm)

The new 'eEurope' initiative recently launched by the European Commission which aims to create a socially inclusive information society - and a mandatory requirement for public service internet sites including all government sites to be accessible to blind and partially sighted people. (http://europa.eu.int/comm/dg10/eurofocus/pdf/4299_en.pdf)

The proliferation of new Internet devices (see http://devices.internet.com/). Those already connected include cell phones, Personal Digital Assistants such as Palm Pilots, televisions, games consoles and pagers.

Internet-enhanced cell phone have been available since early 1999 It is estimated that half of the population of industrialised countries will be carrying wireless phones. (http://www.wired.com/news/news/email/explode-infobeat/technology/story/18120.html and http://www.phone.com/index.html)

For a more detailed discussed of the issues, problems and pressures for change in relation to the creation of Accessible Web sites refer to my article "This HTML Kills - Thoughts on Web Accessibility' to be found at http://www.connections.gcal.ac.uk/JimsGuid/HTMLkils.html

"Creating an accessible web site is - after all is said and done - about making sure all internet aware devices can access the information you have put on the web. Whether it be a braille reader machine being used by a disabled person or a business man accessing the web in his car the issues are the same." 'This HTML Kills - Thoughts on Web Accessibility' by Jim Byrne: http://www.connections.gcal.ac.uk/JimsGuid/HTMLkils.html

In the next section of this I will look at the particular problems of making sure that large Web sites built and maintained in a way that ensures they remain accessible. Given that most of the 'tools of the trade' available to Web designers are not up to the job - this is no easy task.

Thoughts on building and maintaining large accessible Web sites

In my opinion you cannot currently build a fully accessible HTML validated Web site without you or the person you have passed the task to knowing how to write HTML - and of course having knowledge of how to create an accessible site. Perhaps this will change in the future; the World Wide Web Consortium have published a set of guidelines for companies creating HTML authoring tools (http://www.w3.org/TR/WAI-AUTOOLS/). I am optimistic that these guidelines will be taken up by the major authoring tools and browser manufacturers - many have already started down the road to conformance.

In general the tools available do not produce accessible Web sites - human intervention is still needed on many occasions. For a further discussion of this and the wider issues of accessibility and the Internet it is worth reading Cynthia Waddel in 'The Growing Digital Divide in Access for People with Disabilities: Overcoming Barriers to Participation' (http://www.aasa.dshs.wa.gov/access/waddell.htm)

There are numerous ways to create Web pages including: writing HTML by hand, saving Word Processing pages as HTML, creating pages using WYSIWYG (What you see is what you get) Editors like FrontPage and using Multi-million dollar web site automation and management tools. The problem with automatically generating your HTML is that you tend not to get accessible Web pages - and lots of editing working has to be done by hand once the site has been created.

If you are building the Web site yourself or if you use one of the specialised Web page development programs I suggest the World Wide Web Consortiums Web Accessibility Guidelines as a good guide to help make your site accessible ( http://www.w3.org/WAI/). Your choice of WYSWYG Web editor should be be based on whether it can assist you in the creation of accessible pages and whether it lets you edit the resulting HTML.

If you decide to enlist the help of a commercial design agency you should ask them if they have experience of creating accessible Web sites and to give you the addresses of some examples. If their eye's glaze over or if there is a stunned silence on the other end of the phone when you ask this question try somewhere else.

Once you have created you Web site there are many tools you can use to evaluate the accessibility of the resulting pages. The World Wide Web Consortiums Web page: Existing Evaluation and Repair Tools provides a good list of what is available (http://www.w3.org/WAI/ER/existingtools.html). Web creation software - assuming they are built in conformance to the guidelines - should automatically include accessibility feature into Web pages.

Help to build accessible pages

Here are some tools that I use:

HTML Tidy: A must have application for any HTML author; cleans up HTML and fixes mistakes and a host of problems and points up some accessibility problems. Has built in support for cleaning up HTML produced by Word 2000 and Word 97. URL: http://www.w3.org/People/Raggett/tidy/

Bobby Accessibility Checker: Using Bobby will tell give you a good idea of how well your pages conform to the World Wide Web Consortiums Web Accessibility Guidelines. Using ‘Bobby’ is only a start it is not able to point to all your access problems and does not work correctly on sites that use Frames. URL: http://www.cast.org/bobby/

Lynx Browser: Always check your pages using a text browser; Lynx is the best. http://www.trill-home.com/lynx.html

Betsie is the filter program used by the BBC to create an automatic text-only version of its website. There are other programs that can convert an design based page to text only ‘on the fly’. URL: http://www.bbc.co.uk/education/betsie/

It is not just about building HTML pages

In reality if you are building and maintaining a large Web site you need a combination of tools which can help you to automate the process - but still allow you to delve in to hand code when needed. One of the most important issues of running a Web site is not about how you create the HTML but how you design systems that make it as easy as possible to let contributers add, modify and delete the documents they have ownership of, manage the file system etc - and still make the end result accessible. Here is a rather long quote from Philip Greenspun that hints at some of the problems:

Why don't these what-you-see-is-what-you-get (WYSWYG) HTML editors enable everyone to become a competent Web publisher? They solve the wrong problem. In the early-ish days of the Web, say 1994, it was observed that college undergraduates who were Unix users could build themselves a Web page in about 30 minutes, even if they were English majors who had never taken a programming class. Users of desktop PCs were unable to produce Web pages at all. Software developers set out to solve what they thought was the desktop user's problem: HTML "programming" is too hard to learn.

He goes on,

It turns out that HTML "programming" consists of sticking "<I>" and "</I>" around a word that you want to appear in italics. Secretaries worldwide were successfully using word processors like this all through the 1970s. Had the average person really become so stupid and lazy in the succeeding 20 years that he couldn't learn that "the I tag is for italics; the B tag is for bold"? In Alan Cooper's interesting book on user-interface design, About Face (1995; IDG), he makes the claim that users don't understand the difference between RAM and disk and further, that they don't understand the file system or directory hierarchies. Somehow people struggle along and get a letter printed but they are confused when they close a document and their word processor asks them if they'd like to save their changes. Save them where? Why weren't they saved before? Why is there a "file" menu on a typical program at all? Shouldn't I just be working on a document and be offered the chance to revert to older versions? Building a Web site exposes and exacerbates all of the problems that users have with their computer systems. No longer are they just trying to print out a letter. They have to organize and link together a set of documents. So if you give someone a WYSWYG editor for HTML, he or she will usually just get stuck 30 minutes deeper into the task of building a site.

Site Management

For large sites a specialised Web site management system is essential - by specialised I don't mean built to order I mean a product whose strengths lies in this area. Something which will allow you to design common templates with dynamic elements, some automated HTML, scripting capability, allow you to manage and easily change the directory structure of your site, perhaps allow you to link in with other HTML generating programs.

So I am not saying "if you want to have an accessible Web site you are going to have to built it all by hand". What I am saying is that we need to be aware of the limitations of automated WYSIWYG Web publishing systems. What is needed is a combination of both automated, 'make my life easier' software, and knowledge - of both accessibility issues and Web Publishing technical details.

There is much more to be said about this, but not in this document. For a more detailed discussion it would be worth having a look at Welcome to the `new Web order' by By Jeff Walsh and Matthew Nelson ( http://www.infoworld.com/cgi-bin/displayStory.pl?/features/990208weborder.htm).

Plan for Change

Jakob Neilson in his book 'Designing Web Usability'' (http://www.useit.com/jakob/webusability/) and in his 'Alertbox' column on the Web suggests a useful pragmatic approach to making large high traffic sites accessible. In essence he suggests the following:

• Start by making your most popular Web pages accessible immediately.
• Follow the World Wide Web Accessibility Guidelines for all new Web pages.
• Develop a longer term plan to convert all other pages - with priority based on the popularity of the pages.

( Disabled Accessibility: The Pragmatic Approach June 13, 1999 http://www.useit.com/alertbox/990613.html )

It may be difficult initially to ensure that every page on a large Web site is accessible but as Neilson himself points out,

I realize that my own pages do not follow every last guideline. I have a very pragmatic approach to usability and may cut a corner in order to meet deadlines or satisfy other design trade-offs. There is a great difference between less-than-perfect design and completely reckless design, though. (Jakob Nielsen's Alertbox, June 13, 1999: Disabled Accessibility: The Pragmatic Approach http://www.useit.com/alertbox/990613.html)

The best start to make is to develop the right attitude and accept that there is a need - which may turn out to be a legal as well as a moral need to - to ensure that the information you produce should be accessible to everyone. The World Wide Web is one of the easiest ways to do this; information published via the Web can be very flexible,

Making the Web more accessible for users with various disabilities is to a great extent a matter of using HTML the way it was intended: to encode meaning rather than appearance. As long as a page is coded for meaning, it is possible for alternative browsers to present that meaning in ways that are optimized for the abilities of individual users and thus facilitate the use of the Web by disabled users. (Jakob Nielsen's Alertbox, June 13, 1999: Disabled Accessibility: The Pragmatic Approach http://www.useit.com/alertbox/990613.html)

Ultimately the aim should be to make every page of information you are providing accessible. Initially this can seem a daunting task - so if the first step is to develop the right attitude, the second step is to develop a plan of action. This plan of action could be based around the suggested steps above and be based on the World Wide Consortiums Accessibility Guidelines.

In the next section I will get down to the real core of this document; the accessibility guidelines themselves.

The Guidelines

In the remainder of this report I will use the Web Accessibility Initiatives guidelines as a framework for my own set of guidelines. I will summarise, interpret, comment and add to as I see fit.

The first paragraph of the Web Accessibility Initiative guidelines states:

These guidelines explain how to make Web content accessible to people with disabilities. The guidelines are intended for all Web content developers (page authors and site designers) and for developers of authoring tools. The primary goal of these guidelines is to promote accessibility. However, following them will also make Web content more available to all users, whatever user agent they are using (e.g., desktop browser, voice browser, mobile phone, automobile-based personal computer, etc.) or constraints they may be operating under (e.g., noisy surroundings, under- or over-illuminated rooms, in a hands-free environment, etc.). Following these guidelines will also help people find information on the Web more quickly.

The Guidelines are divided into 3 different 'priority' levels

Priority 1. requirement must be satisfied - or information will be impossible to access by some groups.

Priority 2. Should be satisfied - if satisfied 'will remove significant barriers to accessing Web documents.'

Priority 3. May be satisfied - if satisfied 'will improve access to Web documents'.

Conformance to the guidelines :

• Level "A" all Priority 1 checkpoint are satisfied
• Level "Double A" all Priority 1 and 2 are satisfied.
• Level "Triple A" Priority 1, 2 and 3 are satisfied.

Guideline 1. Provide equivalent alternatives to auditory and visual content.

A main tenet of this guideline is the provision of text equivalents for non-text content (images, pre-recorded audio, video). Text equivalents can make information accessible to people from various disability groups using a variety of technologies. The provision of text equivalents can make information available to people who surf with graphics turned off ( perhaps due to a slow internet connection) or people with a visual impairment who use a text only browser and a screen reader [Priority 1].

From the W3C guidelines:

Text can be readily output to speech synthesizers and braille displays, and can be presented visually (in a variety of sizes) on computer displays and paper. Synthesized speech is critical for individuals who are blind and for many people with the reading difficulties that often accompany cognitive disabilities, learning disabilities, and deafness. Braille is essential for individuals who are both deaf and blind, as well as many individuals whose only sensory disability is blindness. Text displayed visually benefits users who are deaf as well as the majority of Web users.

Where photographs or graphics are critical to the understanding of a pages content and an ALT attribute cannot be used to provide an adequate description there is another technique which can be used to make the information accessible. A longer text can be provided in a separate file with a link being provided from the main page to this description. The National Center for Accessible Media (http://www.wgbh.org/wgbh/pages/ncam/) recommend that a discrete link text such as "[D]" should appear next to the picture - users can click the link to get a full description.

Navigation on the many sites is based entirely on a set of graphic buttons which run down the left hand side of the page. If none of these graphics have alternative text descriptions and no other navigation method is provided - the site is inaccessible to many people who use text browsers or speech software.

A frequent technique I have come across on Web pages - which can cause access problems - is the use of graphics instead of text- i.e. it looks like text but it is actually just text created in a drawing program and then place in the page to give a particular stylistic affect. Such text is invisible to someone accessing the page using a screen reader. When this technique is used a text versions of the graphic should also be provided

Examples

An example of how to include an ALT attribute:

The HTML for The Connections Disability Web site logo which appears at the top of each page ( http://www.connections.gcal.ac.uk/) is:

<img src="images/mcu13.gif" height=83 width=483 border=0 alt="Connections Disability - Disability Information and News">

Viewing the site with images turned off you will see the text 'Connections Disability - Disability Information and News'.

An example of how to include a LONGDESC attribute to supplement the short description:

<img src="images/mcu13.gif" height=83 width=483 border=0 alt="Connections Disability - Disability Information and News" longdesc="sitemap.html">

All we are doing here is linking to another HTML page which contains a longer description.

Actions Required:

'ALT' attributes should be provided for all graphics and an alternative text based navigation method should be provided. If a longer descriptions are needed the 'LONGDESC' attribute should be used. Where photographs or graphics are critical to the understanding of a page a [D] link should be provided which links to a description of the picture content. [Priority 1]



Guideline 2. Don't rely on color alone.

From the W3C guidelines:

Ensure that text and graphics are understandable when viewed without color.

If there is not sufficent contrast between text and background colours you risk losing a fairly large percentage of your potential audience. Your design will exclude for example, people who find it hard to differentiate between certain colours - of which there are many - and people who surf the Web on Black and White monitors. Using a black and white monitor is not uncommon even in this high-tech day and age; my room mate up here in the University still uses one, and I surfed the Web at home with a small black and white monitor for years. In that time I came across a fair percentage of unreadable Web sites.

If your are using colour alone to convey important information ensure that the same information is available in an alternative format.

The RNIB note that additional problems can be caused by distracting backgrounds or by colour schemes that are 'wired-in' to the design through the over use of, for example, the FONT tag in your HTML. Single colour backgrounds are best - white is the most popular but many people find that white can be tiring on the eyes.

Flexibility is the order of the day as pointed out by the RNIB:

• Ensure that it is possible for users to impose their own colour schemes by changing preferences on their browser. For example some people can only read black on white text and others can only read yellow text on a black background. Use standard size text - which can then be adjusted by visitors according to their own needs.
• No capitalisation - difficult to read large passages of text in capitals, don't use italics again difficult to read.

Do not 'hardwire' the colour of text and background in your pages - ensure that users can substitute their own. If possible try not to use the FONT tag, instead use style sheets wherever possible to format your pages and to set background and text colour.

Action Required

Try to ensure that all information conveyed using colour along are also available without colour. [Priority 1]

Where appropriate change text colour to ensure good contrast between text and background. Test out your pages on a black and white screen and if possible both on a PC and a Mac. Pictures and text will look slightly different on Macs and Pcs due to the different monitor defaults. [Priority 2]

Guideline 3. Use markup and style sheets and do so properly.

From the W3C guidelines:

Mark up documents with the proper structural elements. Control presentation with style sheets rather than with presentation elements and attributes.

The correct validated use of markup assists accessibility. Examples of incorrect use of markup would be using tables for layout, presentation markup to convey document structure, header tags to increase font size, or blockquotes to create page margins.

Many site designers use the blockquote element for example to indent text. The <BLOCKQUOTE> element should only be used to signify a quotation.

Another common example of incorrect markup being used is the use of graphic text heading instead of header tags ( <h1>, <h2> etc). Section headers (H1 - H6) should be used to create structured documents and break up long stretches of text.

In the ideal scenario content should be separated from presentation - with style sheets being used to control layout and presentation. In reality this is very difficult to achieve because of the patchy and inconsistent support for style sheets by the current crop of browsers. To create pages exclusively using style sheets for presentation would - even to support the main browsers - require additional programming so that the type of browser being used by the client could be detected and the correct style sheet served. This is - in the short term at least - perhaps an unreasonable expectation.

This does not rule out the use of style sheets entirely - there are a large set of style rules that are adhered to consistently by the most current and up-to-date browsers. Styles sheets can be used to control font styles for example rather than using the HTML FONT element. They can be used to control margins, text size, and for example background colour for elements such as blockquotes and tables.

The page you are reading right now uses style sheets to control margins, text and background colour, give a contrasting colour to the background of quotes and the main heading, and to set the font style of text and headers as well as many other formatting features. As a result this document looks slightly different on MS Explorer than it does on Netscape. Both versions are however functional and the structure of the document is not altered.

If you are just starting out with HTML it is a good idea to get a good HTML guide which recognises the different between Logical tags and style tags and shows concern with using markup correctly. I would recommend 'HTML: the Definitive Guide' by Musciano which is published by O'Reilly (ISBN: 1565924924)

Examples

Style sheets can be used to format HTML pages. Information about style sheets and their use can be found at:

World Wide Web Consortium: 'What are Style sheets': http://www.w3.org/Style/ 'Everything You Ever Wanted to Know about Stylesheets': http://www.westciv.com/style_master/academy/css_tutorial/

The following is part of an example and would be placed within the HEAD section of your Web page. This particular style sheet sets the background to white

<!--

	body {

	background-color: #ffffff;

	margin-left: 5%;

	margin-right: 10%;

	margin-top: 5%;

	font-family: Arial, Helvetica, sans-serif}

	p {

	font-family: Times-Roman, serif}

	H1,H2,H3,H4 {

	font-family: verdana, arial, san-serif;

	font-weight: bold;

	}

-->

HTML is constantly being updated and changed. Before a document can be tested to see if it conforms to formal HTML grammer there needs to be some indication of the HTML version used when the page was first published. A 'Document Type Declaration' which indicates the appropriate vesion of HTML should be added to the start of the HTML before any other tags.

Document Type Definitions:

e.g If the document contains HTML 2.0 code only, the DOCTYPE should be <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

To define a document as just HTML use: <!DOCTYPE HTML PUBLIC text > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">.

DOCTYPE is not required, and not widely used, but there is no reason to not use it. HTML-validators, that verifies that the tags are written correctly, often requires DOCTYPE-tags. (From HTML Vocabulary 2 by James W Walker http://www.calles.pp.se/sve/index.shtml)

Action Required

Markup should be used according to published guidelines, style sheets should be used for presentation purposes whenever possible and structural elements should be used in preference to presentation elements and attributes. [Priority 2]

An appropriate Document Type Definition should be included so that the HTML in the document can be verified as correct and to ensure that the browser will format the page correctly. [Priority 2]

When using styles sheets try to use relative rather than absolute units in property values.[Priority 2]

{imageRef ("partickAuctionsmall", "Old Partick Auctions", title: "Old Partick Auctions")}

Guideline 4: Clarify natural language usage

From the W3C guidelines:

Use markup that facilitates pronunciation or interpretation of abbreviated or foreign text.

The main language used in a document should be identified via the lang attribute e.g <HTML lang="fr"> if the document is in French. Marking up language changes in a document helps speech synthesizers and braille devices to switch to the new language and make the document accessible to multiligual users.

Acronyms and abbreviations should be marked up with ABBR and ACRONYM and use "title" to indicate the expansion: e.g.

<P>Welcome to the <ACRONYM title="Making Connections Unit">MCU</ACRONYM> Web site.</P>

Examples

The following example identifies the language of the page as English,

<html lang="en">

An example of using the ACRONYM tag:

<ACRONYM title="Hypertext Markup Language">HTML</ACRONYM>

Actions Required

Identify the main language used in the Web pages with the 'lang' attribute and identify changes in the language within the text. Use the ABBR and ACRONYM tags when appropriate. [Priority 3], [Priority 1] and [Priority 3] respectively

Guideline 5: Create Tables that transform gracefully

From the Web Accessibility Guidelines guidelines:

Ensure that tables have necessary markup to be transformed by accessible browsers and other user agents.

This guideline states that tables should only be used for 'tabular information' and not for layout purposes. As most Web sites designers will know, this guideline is virtually impossible to stick to due to the inadequate support for styles sheets in most browsers and the weak layout powers of HTML. The W3c guidelines acknowledge this by providing checkpoints that address the accessibility issues if tables are used for layout purposes:

5.3 Do not use tables for layout unless the table makes sense when linearised. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearised version). [Priority 2] Note. Once user agents support style sheet positioning, tables should not be used for layout.

'linearised' means the contents of the cells in the table should be capable of being displayed as a series of paragraphs by older or text browsers. The correct use of markup should ensure that this is possible.

5.5 Provide summaries for tables. [Priority 3] For example, in HTML, use the "summary" attribute of the TABLE element.

The provision of a summary via the "summary" attribute is particularly useful for non-visual readers. The summary states the purpose of the data in the table.

Examples

Here is an example of a summary attribute added to the <TABLE> tag: <TABLE BORDER=1 WIDTH="540" CELLPADDING="20" CELLSPACING="0" align="center" summary="This table is used for layout purposes only - style sheet are just not up to the job yet">

Action Required

If tables are used they should not be used for layout purposes. Complete compliance with this guideline is unlikely given current browser technology, user agents and HTML editors. Where appropriate an alternative version ( i.e linearised ) of the information provided in tables should be provided.[Priority 3] The summary attribute should be added to the <TABLE> tag. [Priority 3]



Guideline 6 and 9

Guideline 6 : Ensure that pages featuring new technologies transform gracefully.

and

Guideline 9 : Design for device-independence

These guidelines to my mind are closely related so I will deal with them together.

It is a good idea to use new technologies which solve problems that have arisen from the use of existing technologies - but new pages should still work on older browsers or browsers designed for users with particular requirements. Example of using new techniques is the use of style sheets for layout and formating or using Frames to provide consistent navigation.

Style sheets

If you use style sheets to layout and format your document ensure that it can be read without the style sheet. Organising the document logically with correct use of structured HTML should ensure that this is the case.

Scripts, applets or other programmatic objects

Pages should still be usable when programmatic ojects are turned off - when this is not possible the information should be provided in an alternative accessible format.

The use of Frames

On pages which use frames the page is made up of more than one window.




In general there are problems with the use of Frames. From the Web Accessibility Guidelines:

For visually enabled users, frames may organize a page into different zones. For non-visual users, relationships between the content in frames (e.g., one frame has a table of contents, another the contents themselves) must be conveyed through other means. Frames as implemented today (with the FRAMESET, FRAME, and IFRAME elements) are problematic for several reasons: * Without scripting, they tend to break the "previous page" functionality offered by browsers. * It is impossible to refer to the "current state" of a frameset with a URI; once a frameset changes contents, the original URI no longer applies. * Opening a frame in a new browser window can disorient or simply annoy users.

A site which uses frames can cause particular problems for people who are blind or have a visual impairment. There are techniques that can be used to overcome these problems, e.g. give each frame a title, provide text equivalents for frames, ensure documents are readable without frames.

It is possible to use frames and still have a web site which is accessible to most of your audience, although some screen readers cannot operate successfully on such sites.

If using a text only browser and the frames on a site do not have titles there will be no indication of where each link takes the visitor.

Also from the Web Accessibility guidelines:

6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2] For example, in HTML, use NOFRAMES at the end of each frameset. For some applications, server-side scripts may be more accessible than client-side scripts.
12.2 Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone. [Priority 2] For example, in HTML, use "longdesc," or a description link.

The NOFRAMES tag can be used to provide information for those visiting the site using a browser that cannot display frames. Many sites use the NOFRAMES tag which is good practice, but on many occasions the text provided via this method is less than helpful. Here is the text of a typical example,

"Our web site requires a frames capable browser. We recommend Microsoft Internet Explorer. For a free download click here"

Not friendly and not useful to someone who cannot use the most up to date Web browser.

Actions Required

Ensure pages can be read without the style sheet. Organising the document logically with correct use of structured HTML should ensure that this is the case.[Priority 1]

Pages should still be usable when programmatic ojects are turned off - when this is not possible the information should be provided in an alternative accessible format. [Priority 1]

Make Frames based sites more accessible through appropriate use of the NOFRAMES tag. Use appropriate titles for the frames, and if more information is required use the 'longdesc' or a description link.

Provide a 'no-frames' version of the Web site.

Even better redesign your sites to get rid of the fames.



Guideline 7: Ensure user control of time sensitive content changes.

From the W3c Guidelines:

Ensure that moving, blinking, scrolling, or auto-updating objects or pages may be paused or stopped.

Moving objects or pages that periodically refresh can be a distraction for people with cognitive disabilities and moving text it can be unreadable for people with visual impairments. When pages contain moving objects there should be an obvious way to turn then off.

Actions Required

Avoid flickering, blinking moving or scrolling objects unless the user can turn of or control them. [Priority 2]

Guideline 8: Ensure direct accessibility of embedded user interfaces

Ensure that the user interface follows principles of accessible design: device-independent access to functionality, keyboard operability, self-voicing, etc.

Some devices/services embedded within Web pages have their own interface. When this is the case the interface must be accessible. If this is not possible and the function of the device is important an alternative which fulfills the same function should be provided.

Actions Required

Ensure that devices/services embedded within Web pages are accessible or compatible with assistive technologies.[Priority 1]

Guideline 10: Use Interim solutions

Use interim accessibility solutions so that assistive technologies and older browsers will operate correctly.

Some older browsers have problems - among other things - with the use of Frames, empty fields in forms, and lists of consecutive links.

Examples

Forms are made more accessible by ensuring that text input form elements have a default value and explicit labels for controls that do not automatically have labels associated with them are provided:

<FORM action="..." method="post">

<P>

<LABEL>

	First Name

		<INPUT type="text" name="firstname" value="First Name">

</LABEL>

<LABEL>

	<INPUT type="text" name="lastname" value="Last Name">

		Last Name

</LABEL>

</P>

</FORM>

Actions Required

The Checkpoints related to this guideline apply to issues that are expected to be resolved in the future due to advances on the side of 'user agent' functionality - such as screen readers that can deal with side-by-side columns of text, the rendering of adjacent links correctly, place holders in edit boxes and text areas. Most of these checkpoints are Priority 3.

The only Priority 2 checkpoint relates to making sure that feedback forms are accessible - first by ensuring each text input form element has a default value and secondly by providing explicit Labels for controls that do not automatically have labels associated with them.

Guideline 11: Use W3C technologies and guidelines

(http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c)

Use W3C technologies (according to specification) and follow accessibility guidelines. Where it is not possible to use a W3C technology, or doing so results in material that does not transform gracefully, provide an alternative version of the content that is accessible.

When available and appropriate use the latest W3C technologies such as style sheets and the latest version of HTML. Avoid using 'deprecated' features such as the <FONT> and the <CENTER> tags - use style sheets instead . [Priority 2]

Actions Required

If the current Web site design cannot be altered to ensure accessibility provide a text only based alternative which is updated at the same time as the main site. The link to the text based site should be located on the top left of each page - and should be context sensitive, i.e. it should lead to the text equivalent of the page that is currently being viewed. There should also be a link back to the graphic version of the site also at the top left of the page and context sensitive.

Guideline 12: Provide context and orientation information.

From the Web Accessibility Guidelines:

Provide context and orientation information to help users understand complex pages or elements.

From the guidelines:

Grouping elements and providing contextual information about the relationships between elements can be useful for all users. Complex relationships between parts of a page may be difficult for people with cognitive disabilities and people with visual disabilities to interpret.

When using frames navigation and identification can be greatly improved by giving each frame a title. This can be done by the use of the "title" attribute on FRAME elements. [Priority 1]

Where appropriate divide information into manageable groups, e.g. use section headers (H1 - H6) and paragraph tags (P) correctly to create structured documents and break up long stretches of text.

Actions Required

Use section headers (H1 - H6) and paragraph tags (P) correctly to create structured documents.

Describe the purpose of frames where this is not obvious by title alone. [Priority 2]

Guideline 13: Provide clear navigation mechanisms

From the W3c Guidelines:

Provide clear and consistent navigation mechanisms -- orientation information, navigation bars, a site map, etc. -- to increase the likelihood that a person will find what they are looking for at a site. Clear and consistent navigation mechanisms are important to people with cognitive disabilities or blindness, and benefit all users.

The use of alternative text or descriptions is particularly critical when it comes to navigating through the site. If the only navigation aids are in the form of graphics, then the site is inaccessible to those who require text based navigation clues to use your site. If using a server-side image map provide redundant text links for each active region of the map.

Inconsistencies in the navigation method used on the site can be confusing - particularly for blind or visually impaired users who expect to find the navigation aids on the same part of the screen on each page.

An alternative text based navigation method should be provided when an image map is used for navigation. Providing bulk of the navigation at the bottom of the page rather than at the top is helpful for blind or visualy impaired people who use screen readers - they do not have to click through every link at the top of the page every time they open a new page.

Text used for links should be short but still give an indication of what is being linked to. the title attribute can be used to further clarify the target of the link.

Providing users with a way of visualising the layout - such as a site map, index or contents page - is helpful. Some sites also provide 'Yahoo like' directory listings giving users an indication of where they are in the structure of the site.

Provide Meta Data

From the guidelines:

Provide meta data to add semantic information to pages and sites. [Priority 2] For example, use RDF ([RDF]) to indicate the document's author, the type of content, etc.

Examples

Meta tags are used to provide a description and a set of key words which describe the content of your site - they should be added to the HEAD section of your Web site. Search Engines use this information to decide what your site is about and how to index it.

Here is an example from the Connections Disability Web site:

<META NAME = "DESCRIPTION" CONTENT = "Glasgow and Scotland Disability Information, News, Chat and Classified Ads. Helping voluntary / statutory sector organisations to use the Internet to provide accessible information to disabled people. "> <META NAME = "KEYWORDS" CONTENT = "Disability, Information, Disabled People, Glasgow, News, classifieds, Handicap, Independent, Living, Health, Personal, Assistant, computer assisted, Legislation, aids and equipment, voluntary sector">

Provide an alternative text based navigation method and add alternative text to the current graphic buttons.

Action Required

Provide a consistent navigation system throughout the Web site. [Priority2]

Provide appropriate meta tag information.[Priority2]

Provide an index, site map, table of contents which gives users information about the structure of the site and where they are within that structure. [Priority2]

Guideline 14: Ensure that documents are clear and simple

From the W3c Guidelines:

Ensure that documents are clear and simple so they may be more easily understood.

There is not much more I can say about this guideline other than it is stresses the need for consistent layout and clear easy to understand language.

Summary and Recommendations

1. 'ALT' attributes should be provided for all graphics and if the navigation of the site is based on the use of graphic buttons or maps an alternative text based navigation method should be provided. Where photographs or graphics are critical to the understanding of a page a [D] link should be provided which links to a description of the picture content.
2. Style sheets should be used for presentation purposes whenever possible and structural elements should be used in preference to presentational elements and attributes. Include and appropriate Document Type Definition.
3. Identify the main language used in the Web pages with the 'lang' attribute. Use the ABBR and ACRONYM tags when appropriate.
4. If you would like a frame based layout provide an alternative version with the same information but in a more accessible format:
5. Make the Frames based site more accessible through appropriate use of the NOFRAMES tag. Use appropriate titles for the frames, and if more information is required use the 'longdesc' or a description link.
6. Provide an alternative 'no-frames' text based navigation method - a text navigation bar at the bottom of each page is the recommended method although this would not work with the current frames based Web site.
7. Use section headers (H1 - H6) and paragraph tags (P) correctly to create structured documents.
8. Provide an alternative text based navigation method.
9. Provide appropriate meta tag information.
10. Where it is not possible to make a page accessible a 'text only' alternative should be provided. This text page must be maintained with the same frequency as the original page.
11. It is good practice to provide a date on the bottom of each page which indicates when the page was last updated. It is also good practice to provide contact information at the bottom of each page.


Validate HTML and Style Sheets

Accessibility is increased when valid HTML and style sheets syntax is used. Use an HTML checkers to test the validity of Web pages from the early stages of development.

Test for accessibility

To test the accessibility of a Web site you can use the 'Bobby' (http://www.cast.org/bobby/) accessibility checker developed by the Center for Applied Special Technology (CAST).

A list of "Existing Evaluation and Repair Tools" can be found on the Web Accessibility Initiatives pages.

Useful Links

Disability Rights Commission: http://www.drc-gb.org/drc/default.asp
"NCAM/Web Access Project": http://www.wgbh.org/wgbh/pages/ncam/webaccess/index.html
World Wide Web Accessibility Initiative: http://www.w3.org/WAI/
The Royal National Institute for the Blind (RNIB) on their Web site ( http://www.rnib.org.uk)
http://devices.internet.com/
http://www.disability.gov.uk/drc/index.html
"This HTML Kills - Thoughts on Web Accessibility' to be found at http://www.connections.gcal.ac.uk/JimsGuid/HTMLkils.html
'The Growing Digital Divide in Access for People with Disabilities: Overcoming Barriers to Participation' (http://www.aasa.dshs.wa.gov/access/waddell.htm)
"TRACE: Designing More Usable Web Sites" : http://www.trace.wisc.edu/world/web/
"Accessibility Issues in Web Design" : http://www.mtsu.edu/~itres/help/Accessibility/index.html

Footnotes:
1. HTML stands for Hypertext Markup Language - which is a set of tags used to 'Mark-up' a document and thus tell the browser which bits of the text are headers, which bits of the text are paragraphs and which bits are to be bold etc. The computer the page is being viewed on can then format these bits of text appropriately.

[ register for updates ]