Roger Hudson, October 2005

By some estimates over 80% of the disabilities experienced by people in our communities are invisible to the wider population; so it is not surprising most website developers and proprietors believe that very few, if any, people with disabilities use the Web.

Even in terms of the more profound and obvious disabilities, such as blindness or cerebral palsy, very few web developers have had the benefit of seeing how the different assistive technologies enable people with these disabilities to use accessible websites.

Two of the most common questions I get asked are: How many people have disabilities? And, what sort of technologies do people with disabilities use to access the Web?

In this article I hope to throw a little light on these questions.

How Many People are Disabled?

The diversity of the human population encompasses a vast range of physical, sensory and intellectual differences. Use of the label “disability” always causes me some uneasiness, largely because it suggests the overarching removal of an “ability”. There are many people, myself included, who may have a condition that could be categorised as a disability, but who do not consider themselves disabled. A significant proportion of the deaf community, for example, do not see themselves as disabled in terms of hearing, but as active members of a distinct cultural group with its own traditions, choices and languages.

This said, I do use the words disability and disabilities. They are convenient labels for discussion about ways to improve websites so that they can be used effectively by people with a range of visual, aural, physical and intellectual abilities, including those with impairments in one or more of these abilities.

Trying to determine how many people have different disabilities in a society can be difficult. For a start, there is considerable variability in the way information about the incidence of different disabilities is collected. It appears to me, that it often relies on self-reporting by the person with the disability or their carer, rather an objective collection of the data by an independent person. Also, the level of impairment that determines the criteria for whether a person is considered to be disabled varies from country to country, and in some cases within a country.

Not withstanding these difficulties, it is pretty safe to say that somewhere between 10% and 20% of the population of a developed country like Australia has a disability that will affect their ability to use the Web. The proportion of the population with a disability appears to be increasing, due mainly to the aging population profile of these countries.

The incidence of disabilities (and limiting illness) that restricts a person’s ability to function in everyday life, as recorded by government agencies in some countries:

• United Kingdom, 18% of the population (National Statistics, 2001).
• Australia, 17% of the population (Australian Bureau of Statistics, 2003).
• United States, 19.3% of the population (US Census Bureau, 2000).
• Canada, 12.1% of the population (Statistics Canada, 2001).
• New Zealand, 20% of the population (Statistics New Zealand, 2001).
• European Union, across the 15 EU countries in 2001, 19.3% of the population was hampered by physical or mental health problem, illness or disability, with 9.3% severely hampered. (Eurostat, 2003)

Survey of Disability in Australia

The Australia-wide “Survey of Disability, Ageing and Carers” (SDAC) conducted by the Australian Bureau of Statistics (ABS) in 1998 found that 20.1% of Australians had a disability. The results of the next SDAC survey in 2003 were very similar, with 20% of the population, or 3.95 million Australians, reporting a disability. The ABS survey defined disability as:

“Any limitation, restriction or impairment, which lasted, or is likely to last for at least six months and restricts everyday activities. Examples range from hearing loss which requires the use of a hearing aid, to difficulty dressing due to arthritis, to advanced dementia requiring constant help and supervision.”

Disability, Ageing and Carers Survey (2003): Summary of Findings (PDF)

In both the 1998 and 2003 surveys, about 17% of the population had disabilities, which resulted in restrictions in one or more core activities, such as self-care, mobility and communication, or restrictions in schooling or employment. And, about 3% reported disabilities without any specific limitations or restrictions. 10% of people in Australia use equipment or an aid to help them cope with their condition or manage with their everyday life.

The people with disabilities in the 1998 SDAC were asked to indicate which disability most affected their daily lives.

The SDAC also reported the disability rates for people of different ages in the population: Less than 4% of children between 0 – 4 years had a disability; for people 35 – 39 years the rate is about 15%; for those 65-69 the rate has increased to about 40%; the rate then increases rapidly to more than 90% for people 90 and over. In general, the disability rates for males and females is very similar, although women over the age of 80 have a much higher rate of profound or severe disabilities than men of the same age.

US snapshot for comparison.

US Census 2000 reported 49.7 million Americans over the age of 5 (19.3% of the population) with a long-lasting illness or disability.

• 6.3% with sensory disability involving hearing or sight.
• 8.2% with a condition limiting basic physical activity (eg walking, lifting).
• 4.8% with a condition causing difficulty in learning, remembering or concentrating.

21.3 million people over the age of 16 (11.9%) had a condition that affected their ability to work.

US Census Bureau, “Disability Status: 2000”. Issued 2003. (PDF)

Students with disabilities

Research by Jaye Johnson from Edith Cowan University in Western Australia provides a useful insight into the incidence of disability among young people in the community.

Within the secondary education sector, there had been an increase in the proportion of the student population with a disability during the period 1997 – 1999. For example, the percentage of students in Year 12 (17 -18 years old) with a disability increased from 1.62% to 2.11% over the three years.

The proportion of students with different types of disability did not change significantly during the three-year period.

Within the post-secondary sector, Universities and TAFE (Technical and Further Education) colleges in Western Australia provided statistics relating to students with disabilities. The proportion of students with disabilities in TAFE colleges was between 1.32% and 3.63% and in Universities between 0.7% and 3.0%. (Johnson felt the 0.7% figure resulted from a data collection issue and was not an accurate reflection of the population).

There were significant differences in the reported types of disabilities. In TAFE, 27% of the students with disabilities had a physical disability followed by 22% with vision impairment. Whereas, in Universities 39% of disabilities resulted from a medical condition and only 9% identified having a physical disability and 9% with vision impairment.

“Indicators in the secondary, post secondary and ABS data suggests that there will be an increasing number of people with a disability over the next 8 – 10 years who may access post secondary education and training. Of these students, it is likely a greater proportion will have severe to profound levels of disability than is seen in the present student population.”

Jaye Johnson, “Students with Disabilities in Post Secondary Education. Issues and Trends For a New Decade”.

Research by the Australian Learning Disabilities Association found, “The incidence of learning disability in Australia, as in other western countries, is suggested to be 10% to 12% of the population, with 4% being severely affected”. Source: What is learning disability?

Assistive Technologies

An assistive technology device, as defined by the United States Assistive Technology Act of 1998 , is any “product, device, or equipment, whether acquired commercially, modified or customized, that is used to maintain, increase, or improve the functional capabilities of individuals with disabilities.”

There is a wide range of computer-related assistive technologies (also called adaptive technologies) that can help disabled people access information that may otherwise be inaccessible to them because of their disability. A short description of some of these technologies follows, for convenience they are categorised as input or output technologies.

Input Technologies

An input technology is a device that allows the user to enter information into a computer. Most people use a standard computer keyboard and mouse to access the Internet and surf the Web. Not everyone however, can use both these devices, for example the mouse, which requires the user being able to see the cursor on the screen, is of little use to many vision-impaired web users who mostly use the keyboard to access the Web.

Thankfully, for people who are unable to use a standard keyboard and/or mouse, other input technologies are available.

Alternative keyboards

There are a variety of alternative physical keyboards. For example, there are ergonomic keyboards for people who have hand and upper limb injuries, keyboards that present the keys in a different order (ABC rather than the conventional QWERTY), keyboards that use large keys and colour coding of the letters for people with cognitive and/or vision impairment and keyguards that can be used to reduce the risk of the wrong key being activated. Also, the layout of some keyboards can be extensively customised to meet the specific needs of individual users.

Onscreen virtual keyboards

Some people are unable to type, perhaps due to impaired mobility, but still require the functionality provided by a keyboard. Specialist accessibility software can be used to display a virtual keyboard on the computer screen that allows users to enter data with a standard mouse, pointing device or joystick. Onscreen virtual keyboards can also help people who do not know how to type.

Alternative mouse systems

The standard mouse can be difficult for people with some disabilities to use. The user needs to be able to see the mouse cursor, and then move the cursor on the screen by moving the mouse across a flat surface in a precise way. The trackball and touchpad are probably the two most widely used alternatives to a standard mouse by people who are able to see the screen, but who have impaired upper-limb mobility.

A trackball is like an upside-down mouse, with the ball on the top and often with several buttons, much like an advanced multi-button mouse. With a trackball the actual device remains stationary and movement or rotation of the ball moves the cursor. Different sized balls can be used and people with significant fine motor skill problems often use a large ball. The ball is usually moved with the hand, but can also be operated with the foot, elbow or a stick held in the mouth.

A touchpad allows the user to move the cursor on the screen by moving a finger across the touchpad surface, as occurs with many laptop computers. Touchpads can be used by people who are unable to hold a device such as a standard mouse or who have very limited mobility, perhaps an ability to move just one or two fingers as may be the case when someone has motor neurone disease.

Some alternative keyboards can also function as a mouse through the use of Mousekeys. Both Windows and Apple operating systems for example, incorporate Mousekeys as an accessibility feature for people who have difficulty using a mouse. MouseKeys allows the user to control the movement of the mouse cursor with the numeric keypad.

Head wands

A Head wand is a simple device that is strapped the users head, and has a protruding stick that is used to type keys on a standard or modified keyboard. People with severely impaired limb mobility, but who are still able to move their head (for example, someone with cerebral palsy) are able to effectively use websites with head wands.

Head wands are often used in conjunction with the StickyKeys accessibility option that is available with both Windows and Apple systems. Keyboard functions that require the simultaneous pressing of two (or more) keys can be done with StickyKeys, since it enables the user to press a key and release it, and then press the other key or keys, and the software acts as though the keys are being pressed simultaneously.

Switches

People with very limited mobility maybe unable to use either a modified keyboard or mouse. A range of adaptive switches is available to help people in this situation use a computer and access the Web. Most switches consist of one (or a few) buttons, which can be activated by bodily movement. For example, a person who can only move their head maybe able to surf the Web by clicking a switch embedded in a headrest, while someone else might require a foot switch.

Other switches are touch free, relying instead on motion sensors, brain activation, or a suck and puff mechanism.

Switches are often combined with specialist software that extends the functionality of the device allowing more complex tasks to be undertaken. For example, auto-complete typing software can reduce the amount of typing required by looking at what the user starts to type and then presenting a range of choices that the user can select from to complete the word or phrase.

Voice (speech) recognition

Voice (or speech) recognition software allows a person to control a computer with their voice. With voice as the input device, speech can be used to open programs, write documents, save work, use the Web and write and send emails. There is a wide variation in the way people speak, so the voice recognition software needs to learn how to recognise the user’s voice and the way they pronounce words. It can also remember commonly used phrases and words and use this information to make predications about what is to be input, thereby speeding up the process.

The accuracy of voice recognition has improved significantly in the last few years however, they still require the user to speak in a voice that is relatively easy to understand. People with disabilities that affect their ability to speak (for example cerebral palsy) may have difficulty using voice recognition as an input technology at this time.

Eye tracking

Eye tracking software allows people to use a computer with nothing more than eye movements. People with little or no control over the movement of their hands, and who also may not be able to speak, can use eye-tracking systems to operate a computer and access the Internet. Some eye tracking software can be combined with a virtual keyboard allowing the user to type by moving their eyes.

Eye tracking systems have the potential to bring very significant benefits to a relatively small number of people. However, at this stage they are very expensive and not widely used as an assistive technology.

Output Technologies

An output technology is a device that presents the data or information from a computer to the user. Most web users are familiar with commonly used output devices such as computer monitors and screens, speakers, printers and projectors. Mobile phones, PDAs, plotters and film recorders can also be used to output website content.

A number of specialised assistive output technologies are available to enable people with disabilities to obtain information via the Web.

Screen readers and talking browsers

Screen readers and talking browsers interpret information that can be visually displayed on a computer screen and then present this information as audio output by synthetic speech and/or as tactile output by Braille display. Screen readers and talking browsers also interpret the input interactions made by the user, for example keyboard strokes, entering search requests and checking form radio buttons. These technologies are widely used by people with little or no vision. They are relatively difficult to learn and use and are usually controlled via a standard computer keyboard.

Screen readers don’t read the screen. Working in conjunction with a web browser (usually Microsoft Internet Explorer) and an Application Programming Interface (eg. Microsoft Active Accessibility) screen readers use the source code of a web page to construct an alternative, accessible representation of the page and the functional components it contains. When a page is coded correctly, most screen readers are able to present (either through speech or Braille) the text on a web page, alternative descriptions for images and multimedia content, as well as identifying headings, lists items, links, frames, tables and form elements.

The most widely used screen readers in Australia are JAWS (available from Freedom Scientific) and Window-Eyes (GW-Micro). HAL and Supernova (Dolphin Computer Access) and LookOut (Choice Technology) are also used in Australia, but more widely used in other countries, particularly in Europe. Recent versions of the Windows and Apple operating systems have built-in screen readers, but the features are limited so they are not widely used by people who depend on a screen reader to access the Web.

Talking browsers are specialised Internet browsers that are able to present the content of a web page as speech in a similar way to a screen reader. IBM Home Page Reader is the most widely used talking browser. The Home Page Reader speaks web-based information as it is presented on the computer screen and allows the user to identify the different elements of the page such as headings and links. Users with low vision can use the Home Page Reader to magnify the screen and change font size and colour.

Braille display

A Braille display is a device that allows a blind person to read the contents of a computer display (or website) as a line of Braille characters. Braille display devices that are used with computers and the Web are often referred to as Refreshable Braille Displays, since the line of Braille characters refreshes as the user moves from one line to the next.

Refreshable Braille devices have a strip of rubberised material under which is a row of pins that can be made to rise and fall by electrical signals. The pins are presented in groups (arrays) of six or eight pins, which when activated form a Braille character, similar to the raised dots of Braille impressed on paper. There are usually 40, 65, or 80 arrays (characters) per line of text, depending on the size and cost of the device. Refreshable Braille displays generally include directional keys, which allow the user to navigate through a document.

When used in conjunction with a keyboard, the Refreshable Braille display enables a person to operate a computer, read text, send and receive e-mail, and browse the Web.

Refreshable Braille display devices are considerable more expensive than screen reading software to purchase and are less commonly used for accessing the Web when compared to screen readers. However, Braille is an essential communication medium for people with impaired vision and hearing.

Screen magnifiers

Screen magnifiers allow people with low vision to access information on a computer screen. The magnification software can increase the size of the information by a pre-determined amount. Most programs offer a maximum magnification of 16 times, but the most commonly used level of magnification appears to be 4 or 6 times magnified.

The screen magnifier increases the size of everything displayed on the screen, not just the text. Web pages that most people can view without scrolling require scrolling when viewed with a screen magnifier since only a section of the page will fit onto the computer screen. The mouse or keyboard is used to scroll vertically and horizontally as the users moves the area displayed in order to see all the content of the page.

Most screen magnification software has the flexibility to magnify the full screen or parts of the screen. These programs also often allow for inverted colours, enhanced pointer viewing and tracking options. Many screen magnifiers also contain screen reading software that can be used to speak the page content if the user wishes.

The most widely used screen magnifiers in Australia and elsewhere include, ZoomText Magnifier (developed by Ai Squared), MAGic Screen Magnifier (Freedom Scientific) and Luna and Supernova (Dolphin Computer Access).

Captions

All of the output technologies considered thus far are primarily concerned with improving the ability of people with impaired vision to access information presented with text or static images. The web however is increasingly becoming a multimedia environment containing video and audio material. Unfortunately, progress in improving the accessibility of this material is slow.

I am not sure if you can describe captioning as an output device, however it is a technique that will allow people with impaired hearing to read a description of audio content. Captions describing visual content can also be rendered by screen reading technologies thereby allowing people who can’t see the content to access the information presented.

Joe Clark, one of the pioneers of captioning, provides a good overview of the issue and captioning techniques in his article, “Best Practices in Online Captioning”.

Jared Smith from WebAIM presented a paper on the subject at the “Technology and Persons with Disabilities Conference 2004”, which also highlighted the need to provide captions for audio web content.

“On the Web, synchronized, equivalent captions should be provided any time audio content is presented. This obviously pertains to the use of audio and video that is played through multimedia players such as Quicktime, RealPlayer, or Windows Media Player, but can also pertain to such technologies as Flash, Shockwave, or Java when audio content is a part of the multimedia presentation.”

Jared Smith, “Captioning Web Multimedia: An Overview of Technologies, Resources, and Tools”.

Device Independence

Many different devices are now being used to access the Web. In addition to the examples of assistive technologies described above, people are accessing the Web with an increasing range of devices including mobile (cell) phones, WebTV, PDAs, Kiosks, and not forgetting of course, the Internet fridge.

The number of web browsers available is also increasing all the time. The Evolt Browser Archive contains over 100 browsers including, the original World Wide Web (NeXus) browser developed by Tim Berners-Lee, text-only browsers like Lynx, Microsoft Internet Explorer (different versions) and the hot new favourite, Firefox.

Ideally, all the components of a website should be able to be accessed by any device or user agent that a web user might wish, or is required, to use. Although this is an ambitious, and some might say unrealistic aim, the W3C Web Accessibility Initiative sees device independence as a key component of web content accessibility.

“Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.

Please note that “device-independent support” does not mean that user agents must support every input or output device. User agents should offer redundant input and output mechanisms for those devices that are supported. For example, if a user agent supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.”

Web Content Accessibility Guideline 1.0

HTML is the original language of the Web, and for a while HTML was the only way information could be made available via the Web. HTML, and its successors, use standards that have been developed by the World Wide Web Consortium (W3C). Today however, in addition to material developed using the standards and formats recognised by the W3C, many websites present content in a variety of other formats, with varying degrees of accessibility.

A lot of words have been written and spoken about the terms accessibility, availability, compatibility and interoperability, with the aim of defining, differentiating and explaining their meanings. Also, there is hot debate about where responsibility lies for making sure all web users, including those with disabilities, can access material on websites. Unfortunately this discussion sometimes swirls around in an esoteric whirlpool.

Clearly, developing a site using only recognised W3C standards and formats will maximise its potential to operate with standard compliant browsers and a wide range of input and output technologies. However, this is not always possible or even desirable. For example, the use of a non-W3C format Flash animation, will in some cases improve the usability and even accessibility of a site for some users.

In recent years, the manufacturers of two commonly used non-W3C formats, PDF and Flash, have significantly improved the accessibility features of their product. It is now possible to develop PDF or Flash material, which can be accessed by a wide range of assistive technologies. Unfortunately however, not all web developers have the knowledge, skill or commitment to ensure the material they develop using these formats is accessible. Also, earlier versions of many assistive technologies such as screen readers, which are still widely used, do not support the recent accessibility enhancements.

Another concern is the ability of different assistive technologies or technology versions to recognise and interpret valid web page code. Many screen reader versions for example, do not recognise all the standard W3C coding options that are available to improve the accessibility of data tables.

Who is responsible for ensuring the content on a website can be accessed by people with disabilities who rely on different devices? Clearly the developer has an important role to play. However as indicated earlier, it is possible to use non-W3C format material in a way that can be accessed by recent versions of some assistive technologies; and, some W3C standards material does not work with some technologies.

Of course, as a site developer you could say, “I have done all I can, and it is up to the vendors of assistive technologies to improve their product and the users of these technologies to obtain the most recent version of these products”.

While this attitude might provide you with some moral comfort and put a little pressure on assistive technology manufacturers, it does little for the person with a disability, who is using a technology that enables them to adequately use most other sites, but not your site or the site of your client.

I take a pragmatic approach to the issue of accessibility. In my view, website content should be able to be accessed and used by the widest possible range of people using the software and hardware, particularly assistive technologies, that are in general use at the time. This means developers should:

• Use recognised W3C specifications and standards appropriately.
• With scripts and applets, avoid the use of device-dependent event handlers such as onMouseOver. If mouse dependent event handlers are used provide keyboard handlers such as onFocus as well.
• Wherever possible avoid the use of non-W3C formats. And when they are required, use a recent version of the authoring program and the accessibility features provided.
• Provide alternative access to information contained in non-W3C format material, ideally in the form of a standard HTML version of the content.
• Check the website material to make sure it can be accessed and used by people who rely on assistive technologies that are in current use.

It sometimes seems that the wish of people like Tim Berners-Lee and Chuck Letourneau for a universal Web, which can be accessed by anyone, anywhere, using any web browsing technology, is a forlorn hope. But it isn’t!

More and more people are working to make the Web a universal medium with content that can be used by people worldwide with different abilities and technologies.

References and more information

• Adaptive Technology Resource Centre
• Australian Institute of Health and Welfare, “Disability and Aging – Australian population patterns and implications (2000)” (PDF).
• Australian Learning Disability Association, “What is learning disability?
• Australian Bureau of Statistics, “Disability, Ageing and Carers Survey (2003): Summary of Findings” (PDF).
• Eurostats, “Hampered in daily activities by any physical or mental health problem, illness or disability (Source: ECHP UDB, EUROSTAT, 06/2003)”.
• Evolt Browser Archive
• Jared Smith, “Captioning Web Multimedia: An Overview of Technologies, Resources, And Tools”. (Technology and Persons with Disabilities Conference 2004)
• Jaye Johnson, “Students with Disabilities in Post Secondary Education Issues and Trends For a New Decade”.
• Joe Clark, “Best Practices in Online Captioning”.
• Mike Paciello, “Making the web accessible for the deaf, hearing and mobility impaired”.
• National Statistics UK, “Health Status: Limiting Long-term Illness or Disabilities”.
• Statistics Canada, “Prevalence of disability in Canada (2001)”.
• Statistics New Zealand, “Disability Counts 2001”.
• US Census Bureau, “Disability Status: 2000” (Issued 2003) PDF.
• WebAIM, “Assistive Technologies”
• W3C, “Web Content Accessibility Guidelines 1.0”.

Prepared by Roger Hudson For the Web Essential Info Night in Sydney – 30 June 2005

• Data and Layout Tables
• Looking for information
• Screen readers and tables
• Identifying a Table
  • <caption> for the Table Title
  • summary for Table Purpose
• Simple Data Tables
  • Abbreviation
  • <thead>, <tbody> and <tfoot>
• Complex Data Tables
  • id and headers
• Very Complex Data Tables
• Keep Tables Simple
• Avoid Columns of Empty Table Cells
• Data Table Accessibility Test
• Conclusion and request
• References and Additional Information

Data and Layout Tables

The table element was introduced with HTML 2.0 in 1994 as a means of presenting data, for example timetables, tabular information about weights, measures, prices etc.

Almost from day one however, Web designers began using table elements to control the layout or presentation of information on a Web page.

And, by the time HTML 3.2 came along, the main use of tables on the web was to control the look of the page rather than the presentation of data in a tabular form.

The use of tables for layout can cause significant accessibility problems and thankfully the work of organisations like the Web Standards Group have seen this use decline in recent times. Complicated layout tables with their masses of cryptic code are no longer cool.

The presentation and layout of web page elements should now be controlled through the appropriate use of cascading style sheets. CSS is the way to go!

This article will discuss;

• How the accessibility of data tables can be improved,
• And, describe a test Russ Weakley and I currently doing into the effective accessibility of different ways to mark up complex data tables.

Many of the examples used in this article are from a web page Russ and I have prepared, which contains data tables using different accessibility markup schemas. A number of people have tested these tables using various assistive technologies and the preliminary results of the tests are presented later in this article.

A quick request and note of caution; please don’t take the examples literally. The content of the tables is very simple, and in some cases we have deliberately made the heading levels much more complex than they need be.

Looking for information

An encounter with the following data table is likely to be three-step process:

1. A quick overview to know what the table is about (eg is it a bus timetable, or is it about the prices of vegetables?)
2. Is it likely to meet my needs? (Is it about the price of peas in Darwin?)
3. Obtain the required detailed information (what is the wholesale price of peas in Darwin?)

With a table like this, most sighted people will achieve the first two steps in almost an instance by looking at the table title and the row and column headings.

For the third task however, they have to locate a particular data cell by looking at row and column headings and using them as reference points.

QUESTION: What is the wholesale price of peas in Darwin?
ANSWER: Easy-peasy for most sighted people: $1.25.

But, what about people with impaired vision who rely on screen readers to use the web and obtain information from data tables?

They can also get the information, if the table is well made and complies with the Web Content Accessibility Guidelines.

Screen readers and tables

At this stage, a quick description of how screen readers interpret data tables is probably worthwhile.

Contrary to the label, most screen readers don’t read the screen. Some screen readers in the past, such as PW Webspeak, did read the screen starting at the top left and reading across the screen from left to right, row by row, down to the bottom right. Screen reading technologies in common use today, including JAWS the most popular screen reader in Australia, read the underlying source code for the page rather than the content on the screen.

JAWS users can have the information in a data table presented in the following ways:

• The whole table can be read line by line, either continuously or with sections selected manually.
• With the keyboard command Atl+Ctrl+Left (or right) Arrow the user can move along rows and JAWS reads out the heading of the actual column plus the content of the cell. Users can also read up and down columns in a similar way.
• With the focus in a particular cell, the keyboard command (Alt+Ctrl+Num Pad 5), will cause JAWS to present the information relating to the selected cell. That is, the cell content and, if the table has been coded correctly, the associated row and column headings.

As can be seen, this approximates the earlier description of how sighted people typically use data tables to obtain information.

Identifying a Table

When you see a data table on a web page it usually has a title or label that identifies the table, for example “Vegetable Prices in Hobart and Darwin”. Also, a quick glance at the table will usually indicate the way it functions, for example products across the top and cities or retailers down the left column.

HTML provides two tags that can help orientate screen reader users and enhance the accessibility of data tables.

<CAPTION> for the Table Title

The title for data tables you see on the web today are often presented outside the table in a separate heading <h> or paragraph <p> element. In some cases they are presented within the table in the top row <tr> or data cell <td>. All of these approaches may cause problems for users of assistive technologies.

The <caption> element is the most accessible way of providing a table with an identifying title. By default, ‘caption’ will place the title in the centre immediately above the table. However, CSS can be used to change the style and on screen position of the ‘caption’ element. For example, the title (caption) can be put underneath the table as is commonly done in scientific and academic publications.

When coding a table, the <caption> should come immediately after the table element and before anything else.

summary for Table Purpose

summary is not a stand-alone element like caption, but an attribute that is contained within the table element. The contents of the summary are not displayed on the screen by graphic browsers but can be outputted by screen readers and Braille displays to assist users of these devices to understand the table.

summary should be used to describe the primary purpose of the table and give an indication of its overall structure. Most assistive output technologies will read the summary first to provide the user with information to help them interpret and use the table. With more complex tables, the summary becomes increasingly important.

The following example is part of the code for the “Vegetable Prices in Hobart and Darwin” table:

<table summary="Wholesale and retail prices of vegetables in Hobart and Darwin. There are two levels of row headings.">
<caption>Vegetable prices in Hobart and Darwin</caption>
...

Simple Data Tables

For data tables, identify row and column headers. [Priority 1] For example, in HTML, use TD to identify data cells and TH to identify headers.”

Web Content Accessibility Guideline 5.1

Sighted web users seeking information from a data table, usually scan the headings at the top of each column and the headings at the beginning of each row to identify those that apply to a particular data cell in the table. A relatively easy task that only requires the user being able to determine what is a heading and what is data.

Unfortunately, data tables on the web often use the standard <td> element for cells that contain both the headings and the data (or information). No problem for the sighted user since they can usually easily differentiate between a cell that contains a heading and one that contains data.

Many assistive technologies however, are unable to differentiate between the two, and will present anything that is contained within <td> tags as data. As a result, users of screen readers and Braille displays sometimes find it difficulty associating the information in a cell in the centre of a data table with the appropriate column and/or row headings, depending on the technology they use and the complexity of the table.

HTML provides an easy and accessible way of overcoming this problem. The <th> element should always be used for column and row headings in data tables. (NB: <th> should never be used with layout tables – Guideline 5.4).

The following table for “plum and pear” prices uses <th> for the headings.


<table border="1" summary="Black plums and bosca pears table with one level of row and column headers">
   <caption>Prices for black plums and bosca pears in Sydney</caption>

   </tr>
</table>


A screen reader like JAWS 5 will read the ‘wholesale’ row like this:

“wholesale, dollar one point OO, dollar one point five O”

If the user wants to know the wholesale price of pears, JAWS will voice the selected data cell like this:

“column three, row two, pears wholesale, dollar one point five O”

Abbreviation

The ‘abbr‘ attribute can be used to provide an abbreviation for long headers so that the entire header is not read out every time. In the example of a simple data table below, ‘abbr‘ is included in the <th> tags for the column headings. Some screen readers will then only read the full headings “Black Plums” and “Bosca Pears” the first time they are encountered, and the abbreviations “plums” and “pears” will be read on all the other occasions.


<table border="1" summary="Black plums and bosca pears table with one level of row and column headers">
   <caption>Prices for black plums and bosca pears in Sydney</caption>
   <tr>
      <td></td>

   </tr>
</table>


<thead>, <tbody> and <tfoot>

For simple tables, the appropriate use of the <th> element described above is all that is required to make a table accessible. With just a little more effort however, we can we can further enhance the accessibility of data tables.

HTML provides these elements so that the rows of a table can be grouped together and presented in three different sections;

• <thead> for table head,
• <tfoot> for table footer
• <tbody> for table body.

<thead> and <tfoot> can be used to provide a row of headings at the top and bottom of a table. These are potentially very useful for long tables that extend over more than one page since they enable the header and footer to be printed on each page. Also, with appropriate browser support, they will allow the body of a table to be scrolled independently while the headings remain on the screen. In the future, this is likely to be very useful for users of handheld devices with small screens.

If <thead> and <tfoot> are used you must also use <tbody> to define the body of the table, that is the part of the table that contains the actual data cells. In fact a table can have more than one <tbody>.

Complex Data Tables

For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [Priority 1] For example, in HTML, use THEAD, TFOOT, and TBODY to group rows, COL and COLGROUP to group columns,and the ‘axis’, ‘scope, and ‘headers ‘attributes, to describe more complex relationships among data.”

Web Content Accessibility Guideline 5.2

Tables with single levels of column and/or row headings are significantly easier for screen reader users to understand and use. So wherever possible, complex tables with multiple levels of headings should be avoided.

Sometimes however, complex tables are required. Some data tables, for example scientific tables or those of financial institutions, often require more than one level of row and/or column heading. Once again, most people who are able to access the table visually will not find this a problem. However assistive technologies also need to be able to associate these extra levels of headings with the information contained in the data cells.

The two most commonly recommended ways to mark up tables with two or more levels of headings are:

• Use id and headers to link data cells with the appropriate headings.
• Use scope with col (and colgroup) and/or row (rowgroup) to associate all the cells in a column or row.

But which is the most appropriate?

When testing the accessibility of data tables on websites, I often ask experienced screen reader users to obtain specific information from the tables. In general, most complex data tables prove to be inaccessible. However, when id and headers are used appropriately, I have found that the tables tend to be accessible to most screen reader users.

In recent times, I have noticed an increasing use of scope but in my experience this does not appear to be as successful. I will return to the issue of scope later when commenting on our test of the different accessibility schemas for data tables.

id and headers

HTML 4 introduced the ‘headers’ attribute for table cells <td>. This attribute is used in conjunction with the id attribute within a table heading <th> to allow any cell or cells to be associated with a heading or headings.

The following table, which is from the table test page, for orange and apple prices uses id and headers.

QUESTION: what is the wholesale price of imported apples in Sydney?

The use of id and headers means that most people who rely on screen readers will be able to obtain the answer to this question. The source code for part of this table with the relevant id and headers highlighted follows:

<table border="1" summary="Wholesale and retail prices of imported and domestic oranges and apples in Sydney and Melbourne. There are two levels of column headings.">
   <caption>
      Imported and domestic orange and apple prices in Sydney and Melbourne
   </caption>
   <thead>

         <td headers="domestic apples-dom sydney wholesale-sydney">$1.00</td>
      </tr>
      <tr>
         <th headers="sydney" id="retail-sydney">Retail</th>
   ...THE REST OF THE TABLE CODE ...

Using a combination of JAWS keyboard commands, most users will be able to locate the cell that is likely to contain the information they require. They can confirm this is the correct cell by asking JAWS to “say the current cell”.

If the focus is on the appropriate cell ($1.25), JAWS will “say the current cell” like this:

“column three, row four, apples Sydney wholesale imported, dollar one point two five”

Very Complex Data Tables

The table test page contains the following data table about cherry and apricot prices, which has three levels of column headings and two levels of row headings that use id and headers.

QUESTION: What is the wholesale price of imported A-grade cherries in Perth?

Sections of code for the cherry and apricot table follows with the relevant id and headers highlighted.


<thead>
   <tr>
      <td></td>
      <th id="imp" colspan="3">Imported</th>

      <td headers="imp imp-che imp-che-bgrade perth perth-wholesale"> $6.00</td>
      <td headers="dom dom-apr perth perth-wholesale">$1.20</td>
... THE REST OF THE TABLE CODE ...


Although the heading structure of this table is complex, by using a combination of keyboard commands, most JAWS users will be able to locate the cell that is likely to contain the information they require.

With the focus on the appropriate cell ($9.00), JAWS will “say the current cell” like this:

“Row five, column three, imported Perth wholesale cherries A grade, dollar nine point O O”

Keep Tables Simple

As indicated already, multiple levels of column headings can disorientate screen readers users. For example, when JAWS encounters the cherry and apricot table above it will voice:

“table in seven columns and nine rows” (followed by the general table information, summary etc).

The three rows containing column headings are introduced as follows:

• “three columns row one …”
• five columns row two …”
• seven columns row three …”

There is no indication that these rows contain column headings. Also, users may be left is some doubt about the number of columns in the table. The inclusion of ‘headers’ attributes in the lower levels of column headings (as indicated in the source code above) does allow the different heading levels to be associated when the user asks JAWS to “say the current cell”.

In addition, some preliminary results from the table test page suggest Braille devices can have significant problems with multiple column and row headings.

Wherever possible simple tables should be used; they are easier to code and much easier for people who rely on screen readers to use.

Avoid Columns of Empty Table Cells

Developers sometimes use columns of empty header and data cells to provide a space between the columns in a table.

JAWS, for example, voices the word “blank” every time it encounters an empty cell and this can reduce both the usability and accessibility of data tables for people who rely on screen readers.

CSS rather than empty cells should be used to control the presentation of data tables.

Data Table Accessibility Test

Russ Weakley and I have prepared the Data Table Accessibility Test page to test different ways data tables can be marked up to make them accessible to users of screen readers and Braille devices. The page contains four tables, one simple data table and three complex data, which have more than one level of column and row heading.

We have asked interested people to test these tables with assistive technologies and send us their comments on the accessibility of the different tables.

We are very grateful for the useful feedback we have received from:

• Andrew Downie
• Roger Johansson
• Patrick Lauke
• Bruce Maguire
• David Woodbridge

But we would like more.

If you are interested in contributing, the test tables can be found at: http://www.usability.com.au/resources/tabletest.cfm.

Two of the complex data tables on the test page use id and headers to associated column and row headings with data cells. Another table uses scope with col and row to associate all the cells in a column or row.

At this stage the tables have been tested with the following screen readers:

• JAWS Versions, 4.02, 5.1, 6.0 and 6.2 (JAWS is the most popular screen reader in Australia).
• Window-Eyes 5.0.
• Connect Outloud 2.0.

All these screen readers could effectively access the two complex data tables that use id and headers. The JAWS results with these tables have already been described in this article. Screen reader support for scope however was patchy.

scope, col and row

The use of scope, in association with col and colgroup, is often promoted as an effective way of grouping the headers and information in a column in order to enhance accessibility. Using scope with row and rowgroup is sometimes also suggested, although there is some ambiguity about how this should be done and the advantages in terms of improved accessibility.

The table test page contains the following “Brass and steel nuts and bolts” table, which uses scope, col and row. (I generally don’t use scope, so please let me know if the way scope is used in this table is not correct.)

QUESTION: What is the wholesale price of 10cm brass nuts?

The following section of source code for this table indicates what I believe is the way the scope, col and row attributes are used to provide the answer to this question.


<table border="1" summary="Wholesale and retail prices for 10 and 20 centimetre brass and steel nuts and bolts. There are two levels of column headings.">
   <caption>Prices of Brass and Steel nuts and bolts</caption>
   <colgroup>
   <colgroup span="2">

      <tr>
         <th scope="row">Retail</th>
... THE REST OF THE TABLE CODE ...


It does not appear possible for a screen reader user to obtain the “wholesale price of 10cm brass nuts” from this table, which is marked up using scope.

With the focus on the appropriate cell ($1.25), JAWS 5.1 will “say the current cell” like this:

“column three, row four, brass wholesale, dollar one point two five”

NB: the “10cm” size and “nuts” headers are not voiced.

With JAWS 6.2 the result is:

“column three, row four, brass nuts wholesale, dollar one point two five”

NB: the “10cm” size header is still not voiced. I am not very experienced in the use of scope and would greatly appreciate feedback about the way “Brass and Steel Nuts and Bolts” table has been coded.

Windows-Eyes does not appear to support scope.

Conclusion and request

First, I would like to once again stress the importance of making data tables as simple as possible. Data tables with more than one level of headers are harder to code and much harder for people who rely on assistive technologies to use.

At this stage, it appears that id and headers are the most effective way to make complex data tables accessible. Although id and headers are slightly more difficult to code than scope, the apparent poor screen reader support for scope means that this is probably not an effective accessibility option.

Finally, a request, if you have the time please check out the Data Table Accessibility Test page and if possible test it with different technologies. I would be very grateful for any feedback on the quality of the code used for the tables on the page and how well screen readers and Braille devices can access them.

References and Additional Information

BOOKS

• Clark, Joe. 2003. “Building Accessible Websites” New Riders Publishing, Indiana.
• Paciello, Michael. 2000. “Web Accessibility for People with Disabilities”, CMP Books, Kansas.
• Slatin, John and Rush, Sharon. 2003. “Maximum Accessibility”, Addison-Wesley, Boston.

WEBSITES

• World Wide Web Consortium. “Web Content Accessibility Guidelines 1.0.“
• Thatcher, Jim. “Web Accessibility for Section 508“.
• Byrne, Jim. “Table Manners: Creating accessible Tables for both layout and data“.
• Webaim. “Creating Accessible Tables“
• Ferg, Stephen. “Techniques for Accessible HTML Tables“

Over the years, there has been considerable discussion about what is the most accessible way to present tabular information in data tables.

Roger Hudson and Russ Weakley have been studying how people who rely on screen readers use a range of data tables. These observations confirm the need to make data tables as simple as possible.

It is relatively easy to make an accessible data table with one level of row and column headers, however it is not always possible to have just one level of headings. Some data tables, for example scientific tables or those of financial institutions, require more than one level of row and column heading. It is much harder to make a table with multiple levels of row and/or column headings accessible.

We have prepared this page to test different ways of enhancing the accessibility of data tables. We are seeking feedback from website users and developers, particularly those who use assistive technologies.

Please send us your opinions on the accessibility of the different data tables and any suggestions how they might be improved. And, please don’t be distracted by the simplified nature of the content or the number of heading levels used in the complex tables.

Table 1: Lemons and pears – Simple table without scope or headers

Table 2: Oranges and Apples – complex table using id and headers

This table provides information about the wholesale and retail price of both imported and domestic oranges and apples in Sydney and Melbourne. There are two levels of row and column headers.

Table 3: Nuts and Bolts – complex table using scope, colgroup and rowgroup.

This table provides information about the wholesale and retail prices for two sizes of brass and steel nuts and bolts. There are two levels of row and column headers.

Table 4: Cherries and apricots – very complex table using id and headers.

This table provides information about the wholesale and retail price of both imported and domestic cherries and apricots in Sydney and Melbourne. The cherries are presented in two different grades. There are three levels column headers and two levels of row headers.

As the Web evolves, new software and applications for use on Websites are being developed. Many of these new applications are proprietary products that don’t use standard features recognised by the World Wide Web Consortium (W3C). The use of non-standard formats can cause significant accessibility problems for some people.

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.

Many non-W3C formats (e.g., PDF, Shockwave, etc) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies).”

Web Content Accessibility Guideline 11.

This Accessibility Guideline is probably one of the most contentious and difficult to interpret. In many cases the potential accessibility of a non-W3C application that requires specialist software is determined by three factors:

• The inherent accessibility of the application, or application version.
• The availability of user software (readers) to render the application, and the technological capacity needed for that software.
• The ability of current assistive technologies to access content generated by the application and rendered by the user software.

Portable Document Format

PDF has been developed by Adobe for the distribution of electronic documents in a format that retains the exact look of the source material. PDF files can be created by scanning a printed document or by using Adobe Acrobat (writer) to convert an electronic document, which has been produced by another application such as Microsoft Word, Pagemaker or QuarkXPress, into the Portable Document Format.

Adobe also provides Acrobat Reader, free software that allows PDF files to be viewed and printed using a variety of hardware and operating system platforms. The ability of PDF files to look exactly the same regardless of the system used to access them has lead to the increasing use of PDFs on Websites in recent years. The name of the PDF reader was changed to Adobe Reader with the release of Version 6.

PDF is a quick and convenient way to put an existing document on a Website. PDFs are used on Websites for many reasons, some of the most common today are:

• Brochures and information fact sheets.
• Large public documents that contain charts and images, such as annual reports.
• Documents that exist in hard copy but have a very short life, eg press releases.
• Fax-back order/request forms for the user to print out.
• Contracts and agreements for the user to print.
• Secure password-protected documents.

The rapid growth in the use of PDFs on Websites has lead to increasing concerns about accessibility, particularly for the users of screen reading technology, which converts text into synthetic speech or electronic Braille. Before the release of Acrobat 5 in 2001, information presented in PDFs was generally considered inaccessible, although a plugin was available for Acrobat 4 that did provide some access to PDF documents.

Accessibility

PDF is not recognised by the W3C as a standard format. The use of PDF content on Websites is covered, in part, by a number of Web Content Accessibility Guideline checkpoints including:

“Provide a text equivalent for every non-text element. This includes images, graphical representations of text …”

WCAG Checkpoint 1.1

“Ensure that pages are accessible even when newer technologies are not supported or are turned off.”
WCA Guideline 6

The lack of accessibility of PDF documents exposes Websites proprietors to the risk of legal action under laws in many countries that protect people against discrimination. In Australia, the Disability Discrimination Act requires the providers of goods and services through the web to ensure equal access for people with a disability.

Adobe sought to address this problem in three ways.

• Releasing Acrobat 5 software in 2001. With the release of an enhanced update, Acrobat 5.0.5 in January the following year, it was now possible to produce some PDF documents that were accessible to the users of some assistive technologies.
• Converting a PDF document on a Website to HTML or text via a free online tool. Not all PDF documents can be successfully converted using this tool. http://www.adobe.com/products/acrobat/access_simple_form.html
• Providing a conversion service for PDF documents submitted via email. http://www.adobe.com/products/acrobat/access_email.html

An important feature of Adobe Acrobat 5 was the support it offered screen readers via Microsoft Active Accessibility (MSAA) technology for Windows. Acrobat 5.0.5 provided greater integration with the Microsoft Office suite of programs and version 5 and later allowed content to be tagged in a similar way to HTML documents. The Acrobat 5 Reader also offered the potential for users to navigate a PDF via the keyboard and fill in and submit PDF forms online.

PDF Tags are used to define the structure of a document. They can be used to ensure the reading order for content on the page and include the required paragraph attributes needed to reflow text correctly for different screen sizes and devices. Tags also provide a standardized approach to describing text characters, regardless of font, so that a screen reader can read all characters and words correctly.

The release of Acrobat 5 was a significant step in improving the accessibility of PDF documents however; there are still some significant problems, including the lack of PDF accessibility support in non-windows operating systems.

Improved Accessibility

In 2003, Adobe released the substantially upgraded Acrobat 6 promising enhanced accessibility.

“Acrobat 6 and the free Adobe Reader 6 enable users with disabilities to access, read and use Adobe PDF documents and forms – across multiple languages, including Japanese – more easily. And the improved tools for generating, reviewing, and enhancing Adobe PDF files found in the Acrobat family make it easier for authors to create and distribute electronic content that is optimised for accessibility.

Adobe Acrobat 6.0 and Accessibility.

Adobe offers two versions of Acrobat 6: Professional and Standard. Both versions contain greatly improved accessibility features, however some of the most advanced, including the ability to create and optimise accessible PDF forms, are only included in Acrobat 6 Professional.

Acrobat 6 and Reader 6 allow the text in a PDF file to be synthesized into speech using capabilities available in standard Windows operating systems and Mac OS X. This facility only works with basic PDF text files and full access to more complex PDFs is still only available to Microsoft Windows users. The use of Microsoft Active Accessibility (MSAA) means that Acrobat 6 for Windows will also integrate with a range of assistive technologies including recent versions of Braille devices and the two most widely used screen readers, JAWS (from Freedom Scientific) and Window Eyes (from GW Micro).

In some circumstances Website users may want to save a PDF file as a text file. Adobe advises, “Both Acrobat and Reader let a user save Adobe PDF content, including alternative text for graphics, as ASCII text files. Acrobat also offers the option to export text to RTF, XML, HTML and Word (Doc).”

Acrobat 6 contains a facility for automatically converting existing Adobe PDF documents into tagged PDF files that approximate the structure and reading order of the original document. In most cases, tagged files will translate better with a screen reader than untagged files. If the source document however, is not very simple the tagging results may not be reliable and should be checked to ensure the process was performed correctly.

The advances in Acrobat 6 and Reader 6 mean that is now theoretically possible for authors to create quite complex documents including forms in PDF that are accessible to many assistive technology users. However this is only possible if the authors create the documents carefully and with the aim of providing for enhanced accessibility.

Creating Accessible PDFs

To guarantee that a PDF document will be accessible it has to be prepared in strict accordance with the guidelines provided by Adobe and written using the Adobe Acrobat (Writer) version 5 or later.

Adobe provide a 30 page downloadable booklet, “How to Create Accessible Adobe PDF Files”, which describes in detail what is required to create a PDF with enhanced accessibility. The booklet is available at: http://www.adobe.com/products/acrobat/access_booklet.html

Some of the main requirements for preparing accessible PDFs are briefly outlined below:

1. When a paper document is scanned to create a PDF the resulting file is a PDF Image Only file – that is, bitmap pictures of the pages. Although the page can be viewed with Acrobat, the content cannot be recognised by screen readers and so is not accessible. To make a PDF Image Only file accessible the document needs to be “captured” using Adobe Acrobat Capture 3 or the paper capture facility provided with Acrobat 6 and a tagged PDF file created: http://www.adobe.com/products/acrcapture/main.html
2. Text files such as documents generated by word processing or desktop publishing software are the most suitable for making accessible PDFs.
3. Accessible documents must be in the tagged PDF format and this is easiest to do with documents generated with Microsoft Office 2000 or higher. If you are not using Microsoft Office it may be necessary to download the ‘Make Accessible Plug-in’ from the Adobe website for Acrobat 5, use the automatic tagging facility in Acrobat 6 and perhaps create some of the tags by hand.
4. Word 2000 lets you create tagged Adobe PDF files. However the Word document must be well marked up and use styles to format text such as headings and paragraphs. That is, not by highlighting a piece of text and using the font and bold options to change its look.
5. Also, use styles to provide structure to the document. Use the “spacing before” and “spacing after” paragraph properties rather than the enter (return) key to add space between paragraphs.
6. Use the Column command in Word to create columns and the Insert Table or Draw Table tool to create tables.
7. Add alternative text to all images. In Word you can add descriptive text via the Web tab of the pictures Properties dialogue box within the Format menu.
8. All the parts of a composite image should be grouped using the Group command.
9. Use the Acrobat Tags palette and the forms tool to create accessible electronic PDF forms.

Untagged PDF files such as those created with Acrobat 4 (and earlier) can be converted into accessible (tagged) PDF with the ‘Make Accessible’ plug-in developed for Acrobat 5 or from within Acrobat 6. Tagged files created in this way should always be checked with a screen reader for reading order and content sense as well as accessibility.

Information about the ‘Make Accessible’ plug-in and download are available at: http://www.adobe.com/support/downloads/detail.jsp?hexID=88de

When information is provided via a PDF, the link to the document should include a short summary of the information it contains, an indication of the document size in KB file size and page number and an estimated download time at 56 kbps.

Is PDF Accessibility Still An Issue?

The short answer is YES

The commitment Adobe has made to improving the accessibility of PDFs has been widely recognised by disability groups and accessibility advocates and has directly benefited many users of assistive technologies.

The general opinion of the accessibility community world wide however, is that the use of PDFs on Websites still presents a significant barrier for people with disabilities, in particular for sight impaired Web users who rely on screen reader technology.

In Australia, the Human Rights and Equal Opportunity Commission has indicated that the use of PDF documents on Websites is still a significant accessibility issue.

The use of PDF documents on Websites raise five possible areas of concern:

1. Legacy documents. PDF documents generated with early versions of Acrobat that are not accessible and have not been converted into more accessible PDFs. In cases where these legacy documents are no longer relevant the simplest solution to this problem is their removal from the site.
2. Scanned documents. PDF Image Only files created by scanning an existing printed document are often very hard to make accessible.
3. Unused accessibility enhancements. The enhanced accessibility of PDFs generated with recent versions of Adobe Acrobat is only achievable when the accessibility features are used appropriately.
4. Lack of accessible PDF support by all operating systems. Currently full accessibility support is only available for 32-bit Windows environments.
5. Variable assistive technology support for PDFs. Accessibility of PDFs by assistive technologies depends on the manufacturers of those technologies incorporating PDF support into their products. Several manufacturers have done this with recent versions of their products, but for the many users of earlier versions of the technology PDFs will remain inaccessible.

In 2004, the use of PDFs can still cause accessibility problems for some Web users. However over the next few years, the extent of this problem is likely to diminish as older PDFs are removed from Websites, more accessible PDFs are produced and an increasing number of assistive technology users upgrade their devices.

Alternatives for PDF Content

PDFs are a non-standard W3C format that requires the Acrobat browser plug-in to access the information contained in the document. Even though recent advances mean that it is now possible to create a PDF document that can be accessed by a greater number of people, PDFs should not be considered accessible in terms of the W3C Web Content Accessibility Guidelines.

Accessibility enhanced PDFs still can’t be accessed by a range of web users including:

• People who are unable to install the Acrobat reader software.
• People with slow connection speeds who are not willing to install Acrobat.
• People who use operating systems and browsers that do not support PDF.
• People with assistive technology versions that do not support PDF.

“If after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.”
WCAG Checkpoint 11.4

In most cases, the text information contained in a PDF was originally generated in some other format, commonly MS Word or Excel. This original source material can be used (and where necessary modified) to create an equivalent alternative for the information provided in the PDF

The ideal accessible alternative for content provided in a PDF file is an equivalent HTML page that is both valid and accessible.

Where a HTML alternative is not possible, the information should be provided in text format (RTF) and failing this as a Word or Excel document. In these cases, descriptions should be provided for information conveyed via charts, graphs and images.

Where it is not possible to provide an accessible online alternative for some content, for example a complex form or detailed geographic map, contact details such as a phone number and/or email address should be provided so that someone who is unable to access the PDF can still obtain the information in contains.

References and Additional Information

Maximum Accessibility: Making Your Web Site More Usable for Everyone. John Slatin and Sharron Rush, 2003. Addison-Wesley, Boston.

• Adobe Acrobat: Solutions for Accessibility. Adobe
• How to Create Accessible Adobe PDF Files. Adobe
• Is PDF Accessible? AccessIT (National Center on Accessible Information Technology in Education, University of Washington)
• Adobe Acrobat Accessibility Techniques. WebAim
• Quick reference for Adobe Acrobat 5.0 and 6.0. University of Wisconsin-Madison
• Accessibility of PDF Documents. Jim Byrne, MCU Accessible web design consultancy.
• PDF and Public Documents: A White Paper, Janina Sajka and Joe Roeder. American Foundation for the Blind
• World Wide Web Access: Disability Discrimination Act Advisory Notes. Australian Human Rights and Equal Opportunity Commission (HREOC)

As the Web has evolved, new software and applications have been developed for use on Websites. Many of these new applications are proprietary products that don’t use standard features recognised by the World Wide Web Consortium (W3C). The use of non-standard formats can cause significant accessibility problems for some people.

“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.

Many non-W3C formats (e.g., PDF, Shockwave, etc) require viewing with either plug-ins or stand-alone applications. Often, these formats cannot be viewed or navigated with standard user agents (including assistive technologies).”

Web Content Accessibility Guideline 11.

This Accessibility Guideline is probably one of the most contentious and difficult to interpret. In many cases the potential accessibility of a non-W3C application that requires specialist software is determined by three factors:

• The inherent accessibility of the application, or application version.
• The availability of user software (readers) to render the application, and the technological capacity needed for that software.
• The ability of current assistive technologies to access content generated by the application and rendered by the user software.

Flash

Macromedia Flash is a widely used tool for creating multimedia elements. Flash can generate interactive animations that deliver considerable visual impact with relatively small sized files. Flash content is browser independent and looks the same on all graphical browsers that are equipped with the necessary Flash plug-in or reader.

Before the simultaneous release of the Flash MX authoring tool and the Flash Player 6, Flash generated content was inaccessible to many disabled Web users. It was not possible to add alternative text equivalents to the visual content for users of screen readers or caption audio content for users with impaired hearing.

Although Flash presented accessibility barriers for many people with physical disabilities, in some cases the use of Flash enhanced accessibility for people with cognitive and learning disabilities. A concept or process is sometimes considerably easier to understand when it is presented in a simple, elegant animation rather than explained in words.

The Move to Accessibility

With the release of Flash Player 6 in 2002, Macromedia provided a player that supports Microsoft Active Accessibility (MSAA) to serve as a link between appropriately made Flash material and assistive technologies. At the time of the release, only Window-Eyes (from GW Micro) supported the accessible Flash content. A short while later Freedom Scientific released a new version of JAWS, the most widely used screen-reader, which could also access Flash 6 material.

A user who has Flash Player 6 installed, and a screen reader that supports it, can theoretically navigate Flash MX generated content that is exported for Flash Player 6 in much the same way as they would an accessible HTML page. They can read text content line by line, hear descriptions of movies and images and tab from one actionable item to the next.

When they encounter a Flash movie the screen reader loads the movie and notifies the user. “With the Window-Eyes screen reader, the user hears “Loading… load done.” Once a piece of content has been read, the screen reader moves on to read other parts of the Macromedia Flash content and the rest of the page.

A unique feature of Macromedia Flash content is that it may change over time. As the content changes, Macromedia Flash Player 6 sends a signal to the screen reader notifying it that there has been a change. When the screen reader receives this notification, it automatically returns to the top of the page and begins reading it again.”
Macromedia Flash MX Animation (accessed 15 May 03)

Flash however, is not device independent as required by the Web Content Accessibility Guidelines.

“Ensure that any element that has its own interface can be operated in a device-independent manner”.
WCAG Checkpoint 9.2

For people who do not use a mouse to access the Web, Flash content captures the keyboard if the user has Flash Player 6 or lower installed, not allowing the user to tab beyond the Flash. This is a major problem for visual mouse-impaired users and for vision impaired screen-reader/keyboard users. The problem has been solved with Flash Player 7.

Making Accessible Flash

The Macromedia Flash MX authoring tool was designed to help developers create accessible Flash content. The inclusion of an accessibility panel (more later) in Flash MX allows designers to add names and descriptions to whole Flash movies and objects within movies in a similar way to ‘alt’ and ‘longdesc’ text equivalents for HTML images. Text equivalents can also be can also be assigned to buttons, however each graphic should be contained in its own movie clip and given an instances name.

Flash Player 6 automatically presents the text content of any Flash presentation, including text in basic form elements such as input fields and check boxes, to an assistive technological device that supports it.

Designers can use the accessibility tools of Flash MX to hide individual elements that present no content from screen readers. Also, according to Macromedia:

“In the example of a rotating banner ad, a single text equivalent for the entire ad would convey the content of the advertisement to the user and prevent the screen reader from constantly returning to the top of the page.”
Macromedia Flash MX Animation (accessed 15 May 03)

The same Macromedia accessibility page also offers the following warning.

“Designers and developers should refrain from using animated movie clips or other animation within button symbols in Macromedia Flash MX. The use of such animations makes it difficult for screen readers and other assistive technologies to work with buttons.”

Most Flash movies are embedded with two tags; <object>, which is primarily needed by MS Internet Explorer; and <embed> which is used by Netscape and similar browsers to display Flash movies. This practice can cause some compliance problems, primarily because <embed> is non-standard, and can reduce accessibility. Drew McLellan discusses this issue and a possible solution in the A List Apart article “Flash Satay“.

Providing text equivalents for images will be of little value if a vision impaired user who is relying on a screen reader is unable to hear what is being read. If a site contains background music or sounds it is desirable to include an option for muting that sound so that screen reader users are able to hear the text equivalents to the Flash content.

The W3C Web Content Accessibility Guidelines recommend colour alone should not be used to communicate information since people who can’t differentiate between colours may not be able to access that information. Developers of Flash material should remain mindful of this guideline, particularly when it comes to choosing text and link colours. They should also avoid using colours and colour names as action keys, for example “select the red text for the next page”.

Using the Accessibility Panel

A central new feature of Flash MX is the addition of an accessibility panel that enables designers to control the accessibility of a Flash movie and some elements of a movie. The accessibility of graphics can also be enhanced, but only after they are converted into movie clips.

To address the accessibility of a whole movie, rather than the individual elements it may contain, select only the movie. Selecting the different elements in a Flash movie will activate an accessibility panel with the relevant options for that selection.

Make Movie Accessible:

This option is selected by default and can be used to provide a text equivalent name and clear description for a movie. Names and descriptions should also be provided for different elements within a movie as they are created.

Deselecting this option will hide a Flash movie that provides no content from assistive technologies.

Make Child Objects Accessible:

Also selected by default, this feature allows objects (elements) within a movie such as buttons to be more accessible. Screen readers will identify the different objects by speaking their names as they are encountered.

By deselecting this option, child objects can be hidden. In the case of text animation this will also prevent screen readers from reading the animation text.

Auto Label:

When this option is selected Flash will automatically generate a name based on what it can determine about the object from text equivalents and text labels as well as the surrounding content.

Name:

Input field for a short text-equivalent name for a movie or object, similar to alt text. The name should be meaningful and short, less than 256 characters.

Description:

Input for additional descriptive information, similar to longdesc. The description should include an indication of the purpose of an object and any action that may result if that object is selected.

Shortcut:

Can be used to provide a keyboard shortcut to a particular object.

Video Captions and Subtitles

“Flash can be captioned and subtitled, and now that Flash authors can incorporate video into Flash, this is more important than ever. Since caption and subtitle text will change often, it needs to be hidden from screen readers to avoid repetitive voicing of ‘Loading page, load done’.”
Flash MX: Moving Toward Accessible Rich Media (accessed 22 May 03)

This ‘A List Apart’ article by Andrew Kirkpatrick briefly outlines four ways of including captions and subtitles within a Flash video.

Andrew Kirkpatrick coordinates the CPB/WGBH National Center for Accessible Media (NCAM) in Boston. NCAM has developed MAGpie (Media Access Generator), a free multimedia tool for generating captions and audio descriptions in XML files. Flash parses a caption XML file to display the caption data stored in it. MAGpie can also be used to prepare audio description files for a Flash presentation.

MAGpie is available at: http://ncam.wgbh.org/webaccess/magpie/

Conclusion

With the release of Flash MX and Flash Player 6, Macromedia demonstrated a clear ongoing commitment to accessibility that has been widely acknowledged and praised by many people working in the area of disability support. A number of significant issues however, remain unresolved.

For example, some web users are unable to use a mouse and rely on the keyboard or alternative input devices. Many non-mouse interactions with a web page mirror the actions of the tab key and, with a conventional HTML page, the tabbing order can be set. Flash 6 determines the tab order and when this is not optimal it can make tabbing around a Flash page very difficult. Flash also doesn’t enable keyboard access to forms.

Accessibility advocate and author, Joe Clark, outlines some other problems in his ‘A List Apart’ article, “Flash MX: Clarifying the Concept.” (accessed May 2003)

Finally, the key question for website administrators and developers. Is the current version of Flash sufficiently accessible to meet the W3C Web Content Accessibility Guidelines and the demands of the Australian Disability Discrimination Act?

“The provision of information and online services through the Worldwide Web is a service covered by the DDA. Equal access for people with a disability in this area is required by the DDA where it can reasonably be provided.”
World Wide Web Access: Disability Discrimination Act Advisory Notes. Australian Human Rights and Equal Opportunity Commission (HREOC)

The answer to this question is a judgment call. It will need to be made on a case-by-case basis, depending on what the Flash material is being used for and the needs of the user. Some websites use Flash primarily for eye-catching or decorative purposes, for example a flower that blooms or a rotating corporate logo. These decorative elements often do not convey essential information, or at least information that is likely to be pertinent to people with disabilities. In these cases the level of accessibility support now available with Flash MX and Flash Player 6 and 7 is probably sufficient.

On the other hand, some websites use Flash to present navigational elements or to communicate key site content. In these cases, the accessibility limitations of Flash, and just as importantly, the lack of wide spread support for Flash Players by assistive technologies, may cause significant problems for some users. Alternative access to the information contained in the Flash element should be provided, ideally in the form of a standard HTML version of the content.

References and Additional Information

• Maximum Accessibility: Making Your Web Site More Usable for Everyone. John Slatin and Sharron Rush, 2003. Addison-Wesley, Boston.
• ActionScript: The Definitive Guide 2nd Edition. Colin Moock, 2002, O’Reilly.
• Flash MX: Moving Toward Accessible Rich Media. Andrew Kirkpatrick. A List Apart website.
• Flash Satay. Drew McLellan. A List Apart article.
• Macromedia Flash MX Animation
• Macromedia Flash FAQ
• Macromedia Flash Support Center Action Script Dictionary
• Flash Access: Unclear on the Concept. Joe Clark. A List Apart
• Flash MX: Clarifying the Concept. Joe Clark. A List Apart
• Flash News Flash: It’s Accessible. Lisa Delgado. Wired News website.
• Use of Flash on HP.com
• Flash MX Accessibility Issues. Jason Perry. O’Reilly Network
• Accessible Electronic Content: Macromedia Flash
• Flash Usability Whitepaper
• Making Flash Usable for Users With Disabilities. Jakob Nielsen, Alertbox article.