Mature Age ICT Users Online Survey Results

During December 2010 and January 2011, we conducted an online survey of information and communication technology (ICT) users over the age of 60. We have completed the initial collating of these results and they provide a snapshot of internet and mobile phone usage by those older members of the population who are able and willing to participate in an online survey. We are making the result of the online Mature Age ICT Users Survey available in an Excel file for other researchers to download and use as they wish.

The online survey is the first phase of an ongoing research project being conducted by Roger Hudson, Peter Hindmarsh and Russ Weakley. The overall aim of the project is learn more about the use of the Internet and mobile phones by people over the age of 60, get a better understanding of the problems they encounter when using them, and hopefully offer some practical solutions about how they might be addressed. The other two components of the project which we are doing at this time are:
* A physical-world survey with participants of same age group using the same questions as those in the online survey
* Qualitative interviews with the physical-world survey participants, using different mock-ups of a web page to stimulate discussion about issues they might encounter when using the web.

The online Mature Age Internet Users survey provided useful results from 124 participants after we had removed the erroneous contributions from participants whose minds may not have been fully on the job or who may have been up to mischief. We got contributions from people across the whole age-range of the survey (60 to 85+) with over half the participants aged between 60 and 74. We would like to thank all the participants for their survey responses and comments.

We recognise the general limitations of online surveys such as this and hope that the physical-world surveys will go some way towards addressing them. We also acknowledge that there are some specific failings in the structure of this survey and the wording of some questions. And, with hindsight we realise that we could have dropped some of the questions and there are other questions we could have asked. We plan to do some more online and physical world surveys in the future focusing on obtaining more detailed information about specific issue.

Initial overview of online survey results

As might be expected with a web survey, the vast majority of the participants indicated they used the internet everyday (93%) which is significantly higher than is the case with general internet usage surveys, for example the “PEW Internet and Lifestyle” 2009 survey in the US which found that 38% of adults over the age 65 use the internet at least sometimes.

We are still to analyse the survey results in detail, but one thing is clear the myth that older people mainly use the web to research their family history is clearly that, a myth, with fewer than 10% indicating they often use the internet for genealogical research. It seems to us that in general, people over the age of 60 use the web for much the same reasons as their younger counterparts. In relation to questions about how often they use the web to keep up with the news, to buy books and groceries, to find information, and to stay in touch with family and friends, about 75% of participants indicted they used the web ‘often’ or ‘sometimes’ for these purposes. Two possible areas of difference are: Participation in online auctions with 33% of participants indicating they had done so at some time; And, the use of social networking sites and tools like Facebook, Twitter and YouTube, with 54% indicating they use them at least once a week (compared for example with “PEW Generation 2010” survey which found that “73% of Teen and 83% of Millennials (ages 18-33) use social network sites”.

What Next

Peter and I are currently sorting the 39 physical-world surveys and qualitative interviews we conducted and as soon as the results are available I will post them on this site.

We are also planning to write a few more articles which will look in detail at specific areas of interest which we believe have emerged from the surveys and interviews. These articles will consider the similarity and differences in the results obtained from the physical-world surveys and interviews when compared to the results of the online survey. They will also outline some of concerns and difficulties that older users of the web might have and discuss the use of the web and social networking tools for the delivery of government and commercial information and services.

CSUN talk

I will be discussing the results of this research in a paper, “Improving Web Accessibility for the Elderly“, which I am presenting at CSUN 2011 on March 16. The paper will also outline some of the issues older web users have with font size and colour, and canvass various options for how they might be addressed.

Older web users and text size

Our research into use of the web and other information and communication technologies by people over the age of sixty is producing some interesting results. In this article I want to comment briefly on some of the responses relating to the size of text on web pages.

This research, which I’m conducting in association with Peter Hindmarsh and Russ Weakley, has three main components:

  • An online survey of ICT use by people over sixty to gain an overview of the technologies they use, what they use them for, and common problems the might encounter.
  • A real-world survey with participants of same age group using the same questions as those in the online survey
  • Qualitative interviews with the real-world survey participants, using different mock-ups of a web page to stimulate discussion about issues they might encounter when using the web.

We are still collecting and collating the results, however the responses from one of the participants I surveyed yesterday highlighted one of the common threads that are beginning to emerge.

In the online and real-world survey we ask the participants to indicate how often they experience a range of problems when using websites. One of the problems we cite is, “The size and/or colour of the words make them difficult to read.” With the online survey 124 participants answered this question, and;

  • 13% indicated they often felt this was a problem,
  • 46% indicated it was sometimes a problem, and
  • 41% indicated it was never a problem.

The findings of the real-world survey were very similar. The majority of real-world respondents indicated they never felt the size or colour of text was a problem when using sites. However, during the more qualitative aspect of the surveying a different picture emerged.

The mock-ups for the qualitative survey deliberately used text that was a little small but still within the general range what you see on many sites. One version of the mock-up page had icons at the top right of the page for changing text size and providing a high contrast version of the page (the icons were same as those used on other sites); Another version of the page had the word “accessibility” in the footer and no icons; And, the final version of the page had both the icons and the word “accessibility”.

During the qualitative interviews, the participants were asked in an open-ended question to describe the main difficulties they experience when using pages on the web. Although a few participants indicated they had no concerns, over 50% volunteered text size was sometimes a problem. Later however, when the participants were specifically asked if they had ever experienced any difficulties with the size of the writing on web pages and during the discussions, nearly all of the participants said that they sometimes found the text too small. This included some of the people who had initially indicated they had no concerns. The comments from participants included:

  • Not usually a problem, but sometimes the text can be hard to read because of the size
  • This is sometimes a problem – sites are designed by young people with good vision
  • Text is very often too small (but I can increase it with the browser)
  • Text can be small and on some sites colour can be a problem but generally ok
  • Small text is particularly annoying when there is plenty of space

The participants were also asked what they normally did when they found that the words on the page were too small to read comfortably. From the discussions, it appears that less than half of the participants knew that they could change the size of the text on the page. Comments included:

  • I use the browser to make them bigger if I need to
  • If I have to read it, I will try getting closer to the screen or getting someone else to help.
  • I have printed out pages that are important and then made them bigger with a photocopier.
  • I’d have a problem. I’d try another site, or maybe print the page out and see if that is better
  • You can use the zoom to make it bigger
  • Just use ctrl + to increase the size
  • Go to another site if I can’t read it
  • Tend to go past it. If critical you labour by getting closer to the screen
  • I wouldn’t know how to change the size

A participant I surveyed yesterday is in his sixties and he teaches at a university. He uses computers to access the internet and web everyday, makes online purchases and is an occasional user of social networking sites. In short, he is not what you would call a novice user. In keeping with the other survey results, this participant initially indicated he ‘sometimes’ found the text on the page too small. However, when this issue was discussed during the qualitative interview he said, “Maybe 30 – 40% of the time the writing is too small.”

This participant was the only one so far to notice the in-page tools (icons) for changing the presentation of text and said that when they were available, he used them to increase the text if he needed to make it bigger. I then asked him what he did if he found that some text he had to read was too small but the page did not have any in-page tools and he replied, “It depends, with my iPad I zoom, but on the (work) computer I copy and paste the words into a document and then use Word to increase the size.”

One of the interesting things to come out of this part of the survey is the apparent discrepancy between the quantitative and qualitative results when it comes to text size. Why did the participants appear to underplay the issue of text size in the quantitative surveys? Perhaps, the answer lies in a tendency by some people to blame themselves rather than the equipment when they encounter problems? This is not an uncommon situation with older users of information and communication technologies.

Or maybe, it is related to the gradual and unpredictable nature of age-related capability decline as described by David Sloan and others. Sloan argues that in contrast to people with more extreme disabilities, there are fundamental challenges to overcome when it comes to supporting older people with the most appropriate assistive technologies. One of these challenges is making the older person aware that they have accessibility needs, since age-related impairment is often easily discounted or ignored as being just an inevitable part of growing old.

With this awareness, we then have to work out what are the most appropriate solutions and how to deliver them.

Hear more at CSUN

I will be discussing issues associated with the use of ICT by older people and proposals to improving their ability to access web content in my paper, Improving Web Accessibility for the Elderly at the CSUN 2011 conference in San Diego.

Baby Boomers and the Web

When we talk about the Baby Boomer generation, we usually refer to the people born in the years between 1946 and 1964[i], the post-war boom of rapid population growth particularly in countries like the U.S. and Australia. “Baby boomers” are sometimes divided into “early boomers” (1946-55), and “late boomers” (1956-1964)[ii] . In this article I am primarily concerned with the “early boomers”, who are now in their late fifties and sixties, and those people a little older than them from the “Silent Generation”[iii] (1940-1946), who are now mainly in retirement.

Although the total percentage of all web users over the age of 60 is still relatively low, the proportion of people within this age group who are going online is increasing all the time. The “PEW Internet and Lifestyle” 2009 survey in the U.S. for example, reported the percentage of adults 65 and older using the Internet had increased from 15% in 2000 to 38% in 2009[iv]. Similar growths in web usage by older sections of the population have been reported in other countries. The Australian Bureau of Statistics survey in 2006-07 found that the greatest rate of growth in Internet use was by those in 65-74 age group with 28% (up from 20% in 2004-05) of all people in that age group going on line.[v]

In developed countries like Australia and the US, government and business are increasingly looking to the Internet for service delivery. In Australia for example, the 2010 report of the “Government 2.0 Taskforce”[vi] advocated greater use of the internet and, in particular, social networking tools by government agencies. Also many financial services can now be accessed online with computers and more recently mobile phones.

The move to online service delivery offers some clear benefits in terms of cost and improved efficiency. Also, the use of social networking tools could potentially enhance openness and greater community participation in the process of government[vii]. However as more and more essential services go online, there is a real danger that a significant number of older people may be unable or unwilling to access them. For example, see an earlier blog post about a man in his sixties who doesn’t want to go online and feels that his access to information in the real world is diminishing.

Age per se is not a disability, but it does increase the risk for a range of chronic, disabling illnesses including Parkinson Disease and Alzheimer. Also, as a natural consequence of the aging process, our auditory and visual acuity and our fine motor skills tend to diminish and we are likely to find remembering some things more difficulty.

It might be reasonable to assume “baby boomers” should have little difficulty adopting new technologies. After all, the formative years for the “early boomers” were marked by an explosion in personal freedom, social experimentation, better education and greater wealth. At the same time there was growing concern for the welfare of others and greater engagement in the socio-political processes. Bob Dylan told us “The times they are changing” and urged mothers and fathers to, “Get out of the road if they can’t lend a hand[viii]; and Martin Luther King spoke of a better future in “I have a Dream[ix].

The Professor of Psychology at Harvard University, Daniel Schacter, in his book “The Seven Sins of Memory”, however suggests the Baby Boomer Generation maybe particularly prone to memory loss. “These memory deficits are particularly evident when older adults are required to recollect the particulars of an experience, such as exactly when and where an event occurred. Older adults lose specific details and tend to rely even more that younger adults on a general sense of knowing that something happened.” [x]

Clearly, there are elderly people who make extensive use of the internet and in many respects they use it in much the same way as their younger counterparts. However, when it comes to using computers and the adoption of new connective technologies, the ability of “early baby boomers” is highly varied: Although virtually none used computers during their formative years, some as a result of either interest or their work environment became active participants in the personal computing revolution, but there are still many people over the age of 60 who have had very little or no experience with computers.

For the computer literate “early boomers”, the challenges posed by the interactive, interconnected media of today are less likely to be technological, but rather ones of attitude and civic behaviour. The apparent lack of concern for privacy in the social networking space and the highly opinionated, and sometimes brutal, language of the blogosphere and Twitter they find confronting.

The “early boomers” with limited exposure to computers however, can face significant problems when confronted with the need to “go online” in order to access goods and services. The ability to encode new memories declines as we get older and since this group have little or no past experience of computers to build on they are likely to find learning how to use the these new media more difficult than their computer and web literate counterparts.

Most producers of web content appear to give little consideration to the needs and abilities of those over the age of 60. And those who do try to address this segment of the population often make the mistake of lumping them together into a single generic group of “the elderly.”

In association with a couple of friends, Peter Hindmash and Russ Weakley, I am currently researching the use of Internet and mobile phone technologies by people over the age of sixty. If this includes you and you wish to participate, please complete our online survey of “Mature Age Internet Users“.

The results of the survey will be used in future articles on this topic and will be incorporated into a paper, Improving Web Accessibility for the Elderly, which I am presenting at CSUN 2011 on March 16.


[i] “Are you a Baby Boomer?”, http://www.babyboomers.com.au/about-you.html

[ii] “Baby Boom Generation”, Encyclopaedia of Children and Childhood in History and Society, http://www.faqs.org/childhood/Ar-Bo/Baby-Boom-Generation.html

[iii] “The Silent Generation”, (originally described by Time Magazine in 1953 and revisited in this essay) Time Magazine Essay, 29 June 2010, http://www.time.com/time/magazine/article/0,9171,878847-1,00.html

[iv] “PEW Internet and Lifestyle Survey”, 2009, http://pewresearch.org/pubs/1484/social-media-mobile-internet-use-teens-millennials-fewer-blog

[v] “Internet Access at Home”, Australian Social Trends, 2008. Australian Bureau of Statistics http://www.abs.gov.au/AUSSTATS/abs@.nsf/Lookup/4102.0Chapter10002008

[vi] “Government 2.0 Taskforce” (Australia), http://gov2.net.au/

[vii] “Government 2.0 Taskforce Report”, Australia, http://gov2.net.au/report/

[viii] “The Times They Are Changing”, Bob Dylan http://www.justsomelyrics.com/331870/Bob-Dylan-The-Times-They-are-Changing-Lyrics

[ix] “I have a Dream”, Martin Luther King, 1963, YouTube video http://www.youtube.com/watch?v=iEMXaTktUfA

[x] Schacter, D. “The Seven Sins of Memory: How the Mind Forgets and Remembers”, Houghton Mifflin Company, New York, 2001.

Accessing Nav Drop-Downs

Recently I came across a site that has a less than accessible horizontal main navigation bar with drop-down menus containing links to the different pages in each section. This got me thinking once again about the use of drop-downs from an accessibility perspective.

In particular, I thought it might be useful to consider the different ways drop-down menus are used with the aim of hopefully identifying the best way of providing keyboard and screen reader access to the main navigation and drop-down items.

I sent out a request asking people to suggest drop down menus that I should look at. Many thanks Denis Boudreau, Rick Ellis, Thierry Koblentz, Chris Hoffman and Priti Rohra for their suggestions and advice. I would also like to thank Russ Weakley, Andrew Downie and Grant Focas for suggestions, menu testing and help in preparing this article.

My aim with this article is not to look at the technical side of how drop-downs are prepared; rather I am concerned with the user-experience for people who rely on the keyboard to access the web, with and without a screen reader.

It seems that there are three basic types of navigation systems which use drop-down menus:

  1. Full tab, where the user tabs through the main navigation menu and all the drop-down options for each item.
  2. Tab and arrow, where a combination of tab and arrow keys can be used to move between items in the main navigation menu and the drop-downs
  3. Tab and enter, where the main navigation item is not a link and you can tab from main item to main item. When enter is selected on a main item the drop-down is presented and the tab key or arrow key is used to move between the choices.

Examples

The following four examples of different navigation menus with drop-downs can all be accessed with the keyboard and to varying degrees are likely to be accessible to screen reader users. The testing of these sites was done using browsers with JavaScript enabled. (NB: when I refer to using the tab key, this includes shift+tab for moving backwards.)

These examples were tested with the following system configurations: Windows XP and 7 using I.E. 8 and Firefox 3.6; Apple OSX with Safari 5.0 and Firefox 3.6. They were also tested using recent versions of the following screen readers JAWS, Window Eyes and NVDA. With some quirks and subtle differences, the screen readers all appear to behave reasonably consistently. 

1. Full tab

The Museum of East Anglia Life website has a main navigation menu with drop downs that can only be accessed by tabbing.

Screenshot of The Museum of East Anglia Life showing dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, when you tab from one main item to the next, the drop-down menu for the item is presented and it is necessary to tab through all the links it contains in order to move to the next main item. The keyboard arrow keys do not work with either the main navigation or the drop-downs.

Keyboard with Screen reader: With the tab key you move through all the links, similar to above. However if you use the arrow keys, you can just go from main item to main items. It appears that when you use the arrow key to go to a main navigation item and then press the tab key the drop-down menu choices are presented and you can move through the options with either tab or arrow. The presence of sub-items and how to access them is not conveyed to the screen reader user.

2. Tab and arrow example 1

The Mozilla website has main navigation items that can be accessed with the tab key or the arrow keys.

Screenshot of Mozilla website showing dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you can move between the main navigation items using either the tab key or the left/right arrow keys. When on a main navigation item, pressing the down arrow key opens the drop-down and you can use the up/down arrow keys or the tab key to move through the drop-down choices.

Keyboard with screen reader: With the screen readers it was not possible to use the arrow keys to open and use the drop-down menu. However, pressing enter on each main navigation item took the user to the relevant section landing page. If the screen reader user decides to abandon normal behaviour and try the menu with the Virtual Cursor turned off (insert+z with JAWS), the arrow key will cause the content of the drop down menu to be presented. But with JAWS the items are read out as a continuous list so it is virtually impossible to make a specific choice from a menu.

3. Tab and arrow example 2

This example for Yahoo Developers also allows the user to use the tab or arrow keys to move between main navigation items, however the selection of drop-down menu choices appears to be different.

Screenshot of Yahoo developers website dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you can tab from main navigation item to main item and when you press the down arrow the drop-down is presented. If you move from main item to main item with the left/right arrow keys each main navigation item is presented with the drop-down open. You use either the tab key or the up/down arrow keys to move through the drop-down options.

Keyboard with screen reader: The screen reader provides no indication to the user that there is a drop-down or how to access it and without any indication many screen reader users a likely to keep pressing the enter key in the hope of something happening. If the “virtual cursor” is turned off, when you press the down arrow key, the menu is reported but as you move down the drop-down items, with JAWS at least, the screen reader also reads content from the page directly after each item. However, if you use the down arrow to open the menu and then tab through the items just the drop-down items are reported. Yahoo “Communication” drop-down menu contains an item, PIM, which can be expanded to present third level items by pressing the right arrow, but again there is no indication that this item can be expanded or how to do it.

4. Tab and enter

With some sites, the main navigation item is not a link and the drop down menu for each item is accessed by pressing the enter key. It should be noted, that in this example from TJK Design, it appears that “Articles: E-K” page is the active page.

Screenshot of tjkdesign keyboard friendly dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you tab from main navigation item to main item, but the main navigation items are not links to the landing page for each section. When focus is on a main item, pressing the enter key opens the drop-down menu, which can then only be accessed with the tab key. However, when tabbing through the main navigation items, the drop-down menu of the current page is presented when you tab to the main navigation item for that page. You can then use the tab key to move through the drop-down options related to this section.

Keyboard with screen reader: Keyboard access appears to function in the same way as described above, with the screen reader reporting each item as you tab to it and when you tab to the main navigation item for the active page the drop-down opens and you can move through the options, but in this case with either tab key or the arrow keys. For main navigation items relating to pages that are not the active page, pressing enter will open the menu and then you can move through the menu with either the tab or arrow, but tab seems a little easier to use.

Conclusion

After reviewing these menus, I have a far better understanding of why most of the people I know who rely on the keyboard to use the web have a pretty negative impression of drop-downs. Without a mouse, they are difficult to use and it appears that you can not expect them to perform in a consistent fashion.

It is hard to make a definitive statement about which drop-downs are likely to be the most accessible, in part because I think it will depend on the particular circumstances of each site. For example, a site with very few main navigation items and only a few drop-down options is not likely to present a big problem for someone who has to tab through all of them. On the other hand, if the main navigation and drop-downs contains hundreds of links, tabbing through all them could be a serious problem for some people.

From this limited testing, it seems to me that the usability and accessibility of drop-downs for screen reader users and for other people who rely on the keyboard to access the web would be significantly improved if there was a generally agreed (standard) behaviour for drop-downs and information about how to use them without a mouse was available to all users. I think these are the two key issues associated with the use of drop-downs and I would be very interested to know what other people think.

Which is better and why?

  1. Is it better to rely on just the tab key rather than a combination of tab and arrow?
  2. If we do rely just on the tab key, is it better to force keyboard users to tab though all the drop-down options? Or should you allow keyboard users to only tab from main item to main item, for example, and then they make the next level of choices on the section landing pages?
  3. If a combination of tab and arrow keys is the way to go, what is the best approach? And, how many keyboard users would even think of using the arrow keys? Not many I suspect, so what is the best way of informing them?

Ten Common Accessibility Problems

Over the years, I have reviewed the accessibility of a number of sites. This document outlines ten common accessibility issues I have encountered which could result in a site’s failure to fully comply with WCAG 2.0. The document includes links to some of the WCAG 2 advisory Sufficient Techniques provided by the W3C for addressing each issue.

Please note: This is not intended to be a complete list of all possible accessibility problems and the order of the items is of no significance. For full details about WCAG 2.0 go to the “Web Content Accessibility Guidelines” W3C Recommendation 11 December 2008.

Page content

  1. Failure to include text alternatives for images
  2. Use of CAPTCHA
  3. Failure to provide adequate alternatives for other inaccessible content
  4. Failure to use HTML header elements appropriately
  5. Failure to explicitly associate form inputs with their labels (or use the input title attribute)
  6. Failure to ensure sufficient difference between foreground (text) colour and background colour
  7. Failure to identify data tables with Summary or Caption
  8. Failure to mark-up data tables correctly
  9. Failure to ensure sites can be used without the mouse
  10. Use of onChange event handlers with select menus

1. Failure to include text alternatives for images

The need to provide equivalent text alternatives for all non-text content is the first accessibility requirement of WCAG 2.
1.1.1 Non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose (except for a few specified situations). (Level A)
WCAG 2.0 Success Criteria 1.1.1

In practice, this Success Criterion most often relates to the use of the image alt attribute for images that are necessary to understand and/or use a site and a null or empty alt (alt=””) for images that are used for layout or decorative purposes.

1.1: Selected Sufficient Techniques

A: If short description can serve the same purpose and present the same information:

B: If a short description can not serve the same purpose and present the same information as the non-text content (e.g. a chart or diagram):

  • Provide short text alternatives (e.g. alt attribute) AND one of the following techniques for the long description:
    • Long description for non-text content using longdesc (Technique G92).
    • Long description in text near the non-text content (Technique G74).
    • Long description in another location with a link to it that is immediately adjacent to the non-text content (Technique G73).

1.2: Note on use of CSS background images

CSS background images should not be used for important items like navigation elements or headings since they will not be displayed when a site is accessed with a device that is unable to display images. Use of background images in this way is a recognised WCAG 2 failure.

  • Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information (Failure F3).

2. Use of CAPTCHA

CAPTCHA stands for “Completely Automated Public Turing test to Tell Computers and Humans Apart”.

The most common example of CAPTCHA is distorted images of text used as part of a login or registration process. Since this form of CAPTCHA uses randomly generated images without text alternatives they are inherently inaccessible to screen reader users and other people who are unable to access images on the page.

The need to provide an alternative for CAPTCHA is one of the specific exceptions in Success Criteria 1.1.1
1.1.1 Non-text content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose (except for a few specified situations). (Level A)

  • CAPTCHA: If the purpose non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.

2.1: Selected Sufficient Techniques

When non-text content is a CAPTCHA, two things need to be done:

  • Provide a text alternative (e.g. image alt attribute) that describes the purpose of the CAPTCHA (Technique G143).
  • AND

  • Ensure the Web Page contains another CAPTCHA with the same purpose using a different modality (Technique G144). Very often the other modality is audio, but the audio should be discernable and understandable by general web users (i.e. not too distorted).

3. Failure to provide adequate alternative for other inaccessible content

Many websites use proprietary (non-W3C) formats which may not be accessible. PDF and Flash are two commonly used formats that can cause problems for screen reader users.

When PDF and Flash content is prepared well it can be accessible to many assistive technology users, but since some assistive technologies may not be able to access even well made PDF and Flash material it is advisable to provide an accessible HTML alternative.

Web content producers should make PDF and Flash material as accessible as possible because assistive technology support for these formats is improving all the time and it is expected that well made material will be accessible to nearly all assistive technology users in the near future.

At this time, some jurisdictions do not consider PDF and/or Flash to be “accessibility-supported” technologies. For example in Australia, various government authorities stipulate an accessible alternative needs to be provided for PDF material.

There is a lot of advice on the web to help developers make accessible PDF material. A good starting point is the Adobe article “Workflow for creating Accessible PDFs“.

The W3C Techniques document contains a large number of techniques for improving the accessibility of Flash material (Flash Techniques for WCAG 2.0). There are detailed descriptions and examples for each technique.

4. Failure to use HTML Header elements appropriately

The ‘h1’ header element should be used for the main heading(s) of the page. Subsequent headers (h2, h3 etc) should be used to identify and present different sections and sub-sections of the page.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
WCAG 2.0 Success Criteria 1.3.1

The failure to use header elements appropriately reduces the accessibility of sites since it makes it hard for screen reader users to understand the structure of information presented on the page. Appropriate header elements also allow screen reader users to easily navigate to different sections of the page.

4.1: Sufficient Technique

5. Failure to explicitly associate form inputs with their labels (or use the input title attribute)

Screen reader users, and others who are unable to perceive the visual presentation of the information on the page, need to be able to identify the purpose of form inputs (controls).

With most HTML forms, the aim or purpose of each input is identified with a text label that is presented using the HTML “label” element with a “for” attribute that has the same value as the “id” attribute for the associated input. The use of matching attributes enables screen readers to associate the label with the input. Each “id” attribute should be unique.

When it is not possible to provide an explicitly associated label, WCAG 2.0 allows the input title attribute to be used to identify the aim or purpose of the input.

5.1: Sufficient Techniques

  • Using label elements to associate text labels with form controls (Technique H44)
  • Using the title attribute to identify form controls when the label element cannot be used (Technique H65)

6. Failure to ensure sufficient difference between foreground (text) colour and background colour

There are two Success Criteria relating to the colour contrast ratio between foreground (text) and background colours, one at Level AA and the other at Level AAA. And, unlike WCAG 1.0 exceptions are made for differences in text size and the purpose of the text.
1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no contrast requirement.

(Success Criteria 1.4.5 Contrast (Enhanced), which is at Level AAA, requires a contrast ratio of 7:1 and 4.5:1 for large-scale text)

6.1: Sufficient Techniques for S.C. 1.4.3

A: text is less than 18 point if not bold and less than 14 point if bold

  • Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text (Technique G18).
  • Not specifying background color, not specifying text color, and not using technology features that change those defaults (Technique G148).
  • Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast (Technique G174).

B: text is as least 18 point if not bold and at least 14 point if bold

  • Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text (Technique G145).
  • Not specifying background color, not specifying text color, and not using technology features that change those defaults (Technique G148).
  • Providing a control with a sufficient contrast ratio that allows users to switch to a presentation that uses sufficient contrast (Technique G174).

6.2: Note on the use of CSS to provide a background colour

The use of a CSS image to provide background colour for navigation elements or headings can cause problems when the text colour is specified using CSS and no CSS background colour with sufficient contrast is provided for the text.

  • Failure of Success Criterion 1.4.3, 1.4.6 and 1.4.8 due to specifying foreground colours without specifying background colours or vice versa (Failure F24).

7. Failure to identify data tables with Summary or Caption

WCAG 2.0 requires data tables to be presented in a way that allows the tables as a whole to be easily identified by assistive technologies.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
WCAG 2.0 Success Criteria 1.3.1

WCAG 2.0 suggests the “summary” attribute of the table element and/or the “caption” element can be used to identify data tables. The “summary” attribute is probably the more commonly used method. The content of the “summary” attribute is not displayed on the screen however it is read by screen readers. The “caption” element is displayed as the table heading, and is explicitly associated with the content of the table.

7.1 Sufficient Techniques

  • Using caption elements to associate data table captions with data tables (Technique H39).
  • Using the summary attribute of the table element to give an overview of data tables (Technique H73).

8. Failure to mark-up data tables correctly

Unlike WCAG 1.0, no distinction is made between ‘simple’ and ‘complex’ data tables in WCAG 2.0. With all data tables, users need to be able to associate the information presented in each data cell with the relevant row and column headers.

With simple data tables, which have only one level of row and/or column headings, appropriate table markup is all that is required to allow screen reader users to access the information contained in the table. Appropriate markup for simple tables means using the TH element for the row and column headers and the TD element for the data cells.

However, screen readers can only access one level of row and/or column headers that use the TH element. With data tables that have more than one level of row and/or column headers it is necessary to also use the ID and HEADERS attributes and/or the SCOPE attribute.

Wherever possible, simple data tables should be used since they are easier to mark-up and most screen reader users find even well constructed complex data tables with multiple levels of headers, more difficult than simple tables to use.

8.1 Sufficient Techniques

  • Using table markup to present tabular information (Technique H51)
  • Using id and headers attributes to associate data cells with header cells in data tables (Technique H43)
  • Using the scope attribute to associate header cells and data cells in data tables (Technique H63)

9. Failure to ensure sites can be used without the mouse

Not all web users are able to use a mouse so it is important to ensure site pages can also be used with the keyboard. There are two Success Criteria directly related to this issue:
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)
WCAG 2.0 Success Criteria 2.1.1

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
WCAG 2.0 Success Criteria 2.1.2

9.1 Selected Sufficient Techniques

  • Ensuring keyboard control by using HTML form controls and links (Technique H91).
  • Providing keyboard-triggered event handlers (Technique G90).
  • Ensuring that users are not trapped in content (Technique G21).

10. Use of onChange event handlers with select menus

The use of JavaScript on websites is generally accessible since most assistive technologies can now support appropriately used JavaScript. However not all screen readers support all JavaScript “event handlers”, which trigger certain actions when an event occurs.

For scripts that do more than just change the visual appearance of an element, the W3C advises content developers to use event triggers that are device-independent, since many people with disabilities are unable to use a computer mouse.

Some web pages contain form inputs which present options in a drop-down menu that the user can select from. Those forms that use the “onChange” (device-dependent) event handler to trigger JavaScript functions based on a selection from within a ‘select’ element can present accessibility problems for the users of keyboards and some other input devices.

10.1 Selected Sufficient Techniques

See also:

  • Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the status of a radio button, check box or select list is changed (Failure F37).

iPhone, iPad and VoiceOver

Several years ago, I looked at the Apple VoiceOver screen reader and found it wanting. Last week, I returned to VoiceOver and, at the risk of further inflaming the hyperbolic passion of the Apple Fan boys/girls, I must say it is amazing how much difference a few years can make.

Last Friday, Russ Weakley and I visited an old friend, David Woodbridge in Gosford, an hour’s drive north of Sydney on the freeway through sheeting rain. David is a senior consultant for Vision Australia and spends part of his time testing and evaluating adaptive technologies. Formally a dedicated JAWS user, David is now an Apple VoiceOver evangelist. Russ and I were keen to see how David uses VoiceOver with his Macbook Pro and make a video of him using it with the iPhone and iPad.

In the past, many people in the blind community and accessibility advocates, myself included, generally felt that VoiceOver did not have the necessary features to be considered a viable alternative for established screen readers like JAWS and Window Eyes. Today, it appears that VoiceOver is an effective and easy to use screen reader, although it seems that it may take people who are used to the more commonly used screen readers a little time to get use to.

I feel VoiceOver, which is built into the Apple operating system, and NVDA, a Windows screen reader that is available at no cost, now provide screen reader users with real alternatives. And in the process, they will hopefully put pressure on the manufacturers of other, relatively expensive, screen readers to lift their game.

In making the following video, many thanks to David for his knowledge, time and patience, and to Russ for operating the second camera, which provided the essential close-up shots of the devices.

The video is captioned in English and open for translation into other languages if you so wish. A transcript of the video is provided after the video player.

Video Transcript

MAIN TITLE: iPHONE, iPAD and Apple VoiceOver

DAVID: Hi my name is David Woodbridge and I am the senior adaptive technology consultant at Vision Australia. I’m part of the equipment solutions team and my job is to do the adaptive technology help desk. I’m one of the people that do that, and also research and evaluate products, including Apple products. And, one of the exciting things last year was the iPhone 3GS because it actually has all the universal access options built into it. So basically you’ve got a screen reader which is the VoiceOver program on the Mac, it’s now on the iPhone. You’ve go Zoom, the large print software and you’ve got Black on White.

A really cool thing about VoiceOver, especially on iPhone,particularly for sighted people that want to help blind or low vision people out is that under Settings, General Accessibility. What you can actually do is associate the Home button with turning VoiceOver,in my case, on or off. So, if just press my Home button three times [PRESSES HOME BUTTON ON iPHONE THREE TIMES].

iPHONE: VoiceOver off.

DAVID: Now my iPhone is a perfectly standard iPhone so if I need sighted assistance for something they can do it with standard gestures. And then, one, two, three [PRESSES HOME BUTTON]

iPHONE: VoiceOver on.

DAVID: And I’ve got myself an accessible iPhone again. And, basically what happens with VoiceOver, is when you touch the screen [MOVES FINGER ACROSS iPHONE SCREEN]

iPHONE: Clock, maps, photos, calendar …

DAVID: It actually reads out what’s happening. Now some people say, well look that’s okay because you are used to it, but how do you know where things are? What you can actually do with VoiceOver is you can actually do a left finger flick to the left or a right finger flick to the right [FLICKS FINGERS LEFT AND RIGHT ACROSS THE SURFACE OF THE SCREEN].

iPHONE: Weather, Voice memo, notes … [PHONE CONTINUES READING WITH FINGER FLICKS AS DAVID TALKS]

DAVID: And you can move item by item so you’ve got total control over where you are. Now the other really good thing about the screen as far as the screen reader is concerned is that if I take my finger to the top of the iPhone and bring it down slightly [MOVES FINGER DOWN ONTO THE TOP OF THE PHONE SCREEN]

iPHONE: Twelve forty one p.m.

DAVID: I’m now on my status line so I can read all the information about the status of what the phone is doing. So if I flick to the left [LEFT FINGER FLICK]

iPHONE: 67% WiFi, signal. Optus network two bars …

DAVID: Two bars [FLICKS TO RIGHT] and to the right …

iPHONE: Status, 31% battery power.

DAVID: 31% battery power. And I can now just take my finger down to the rest of the screen and I’m back on the main iPhone screen itself. Down the bottom, where you’ve got all your apps that you like to access all the time.

iPHONE: Phone

DAVID: I normally use my home button as an orientation point, so I come down here, go to the left, go up a little bit. [SLIDES FINGER TO BOTTOM AND UP A LITTLE]

iPHONE: Phone

DAVID: So I’ve got Phone to make phone calls [FLICKS RIGHT AND LEFT]

iPHONE: Phone, mail – 95 new items.

DAVID: Mail with 95 new items. Flick to the right again …

iPHONE: safari

DAVID: Safari

iPHONE: ipod

DAVID: and the ipod. But, with the release recently of the ipad the accessibility for the VoiceOver application, in my case, has actually got even more spectacular. And, I’ll just mention one particular feature which really gets me excited. At the moment, if I say bring up my Spotlight search for the iPhone … [iPHONE voice] and I touch my qwerty keyboard [PRESSES KEYBOARD LETTER]

iPHONE: G

DAVID: Ok so I am finding my letters [MOVES FINGER ACROSS KEYBOARD]

iPHONE: G, R, E

DAVID: Now, to put a letter in I normally have to double tap with one finger to put the letter in. So it’s almost a three sequence: Find the letter,

iPHONE: A, G

DAVID: Double tap with one finger

iPHONE: G

DAVID: it puts it in the search. What they’ve actually done with the iPad … [PUTS DOWN iPHONE, MOVES HAND TO iPAD] is if I bring up my search [TURNS iPAD ON]

iPAD: Search iPad, search field …

DAVID: And I touch my keyboard

iPAD: Auto-cap keyboard, capital

DAVID: First thing it says is keyboard so I know I am on the keyboard, second thing it says is, if, I hold my finger down on the screen long enough, it says the phonetic of the character, so …[HOLDS FINGER STILL ON KEYPAD]

iPAD: Capital F, foxtrot.

DAVID: F, foxtrot [MOVES FINGERS ON KEYPAD]

iPAD: Capital T, tango

DAVID: And so on. But the really cool thing is when I find the letter I want [MOVES FINGER ACROSS KEYPAD]

iPAD: Cap, cap, capital G [LIFTS FINGERS – SCREEN CHANGES]

DAVID: Take it off, take my fingers off the screen and it puts the character in straight away. So your accessibility has just increased phenomenally because I’m not having to find the character,double tap it, I just find the character take my finger off and hey presto its going.[PRESSES HOME BUTTON] To come back to the main home screen with the home button. And again I’ve got the same thing that I can do with the iPhone. [PRESSES HOME BUTTON THREE TIMES] I can do one, two, three.

iPAD: VoiceOver off.

DAVID: VoiceOver off. Use it normally. Back on again, one, two three.[PRESSES HOME BUTTON]

iPAD: Voiceover on.

DAVID: And we have got the status line. And what Apple have done this time with the status window is, if I come down from the top [SLIDES FINGER DOWN SCREEN]

iPAD: BEEP SOUND FX, contacts, BEEP, 12.44 p.m.

DAVID: It gives me a bleep when I hit the status area and [MOVES FINGERS DOWN SCREEN] and I can do the same thing, flick left and right [FLICKS FINGERS OVER SCREEN]

iPAD: 39% battery …

DAVID: And if I come down to the dock. I drag my finger down to the dock. [SLIDES FINGER DOWN SCREEN]

iPAD: BEEP, BEEP, dock. Mail forty new items.

DAVID: It gives a double beep, plus it actually says dock. Another really exciting feature of VoiceOver on the iPad is when I am using the iPhone [PICKS UP iPHONE] and I flip it [ROTATES PHONE IN HIS HANDS] to landscape or its upside down VoiceOver actually doesn’t tell me that I am actually moving it. But what the iPad does [PUTS PHONE DOWN NEXT TO iPAD] is that, I’ve currently got this in landscape mode [PUTS HANDS ON iPAD] and at the moment I physically know where my Home button is because I can feel it on the left hand side of the screen. [PICKS UP iPAD] But if I actually rotate my iPAD [ROTATES iPAD BY 90 DEGREES]

iPAD: Portrait

DAVID: OK, so I am now in portrait mode and I know from experience my Home button is always on the bottom. But, if I now flip it to the left …[ROTATES iPAD BY 90 DEGREES]

iPAD: Landscape, Home button to the right.

DAVID: It tells me Home button’s now to the right, so I know exactly where my Home button is and I can go straight to it without any problems at all. If I do a flick to upside down [ROTATES iPAD]

iPAD: Portrait flipped.

DAVID: Portrait flipped, and again I know my Home button is exactly at the top of the screen up here. And if we do another flick [ROTATES THROUGH 90 DEGEES RETURNING TO ORIGINAL LANDSCAPE VIEW]

iPAD: Landscape, home button to the left.

DAVID: Home button to the left and I can put my finger right on it. And just one finally thing I want to show people, because this is the thing that always gets people confused. They say, look I’m pressing the [BEEP SOUNDS] volume up button, and I’m pressing the volume down button, [BEEP SOUNDS] but when I actually go back to my speech [FLICKS ACROSS SCREEN WITH FINGERS]

iPAD: Help, contact, notes …

DAVID: It’s the same volume. So the trick is … [PUTS iPAD ON TABLE] You actually start the screen reader reading and then the volume up and volume down button actually then controls the screen reader voice. So if I do a two finger flick down the screen to start it reading.

iPAD: Calendar, contacts [CONTINUES READING WHILE DAVID TALKS AND CHANGES VOLUME LEVEL]

DAVID: And now when I do it [PRESSES VOLUME BUTTON – iPAD VOLUME DECREASES]

iPAD: Settings, photos, page one of two …

DAVID: Volume’s going down, and back up again [VOLUME INCREASES] And I can do a two finger touch on the screen to stop it talking. So that’s basically VoiceOver on the iPad [PUTS iPAD DOWN ON TABLE]

DAVID: When I’m actually doing web browsing. [MOVES FINGER ALONG DOCK SECTION]

iPAD: Safari – SOUND FX

DAVID: Just quickly …

iPAD: Safari, Apple

DAVID: The way that gestures work on the iPhone and the iPad, besides basically moving your fingers around the screen, one finger, double tapping, there’s actually a system called the Web Rotor. [FINGERS OVER iPAD SCREEN] If I do a two finger rotate … [TWIST/ROTATE TWO FINGERS ON SCREEN]

iPAD: Links

DAVID: I can rotate between different elements on the screen. So, I can do links … [ROTATE FINGERS]

iPAD: Form controls

DAVID: Form controls …. [ROTATE FINGERS]

iPAD: Visited links.

DAVID: And then when I want to move on one of those elements, so let’s go back to links. [ROTATES FINGERS]

iPAD: Form controls, [ROTATE] Links

DAVID: When I flick up and down with one finger [FINGER FLICKS OVER SCREEN]

iPAD: Apple, Store, Mac, iPod ….

DAVID: I’m actually moving up and down the following. And of course, when I get to the one I want to get to, I can double tap. Now the similar gestures for the iPhone and the iPad are exactly the same commands that I would be using with VoiceOver on the multi-touch trackpad on a Macbook Pro. So, once you’ve got a Macbook, an iPhone or and iPad you know how to use the gestures in the whole three systems.

DAVID: [C.U. iPHONE] Okay to finish off, I think I might make a phone call because the iPhone does actually have the ability to make phone calls. So, I am going to go to my phone app. [PRESSES SCREEN – SOUND FX] I’m going to find my keyboard …

iPHONE: Contacts, keypad, keypad, selected.

DAVID: And to speed things up I going to use one finger to find the number, and while my finger is on the screen I’m going to use my second finger to complete the double tap sequence. [ONE FINGER MOVES OVER SCREEN TO LOCATE NUMBER. OTHER FINGER TAPS TOP OF SCREEN]

iPHONE: Nine, nine, three, three, three, [iPHONE FINGER MOVES AND TAPS] four, four, three, three, three, three.

DAVID: And, if I zip down the bottom of the screen.

iPHONE: Seven, star, zero.

DAVID: Find zero, come right down.

iPHONE: Call button.

DAVID: And, if I did a double tap now I would actually make a phone call to Vision Australia.

FADE OUT

WCAG Rethink?

The slides and speakers notes from my CSUN 2010 presentation: “Ten Years of Web Content Accessibility Rules: Time for a Rethink?

Following my talk at the CSUN conference in March 2010, several people have asked me to make available the slides. They also asked if it would be possible to get a transcript since many of the slides just contain a few words to highlight what I was saying.

SUMMARY

My presentation was primarily concerned with whether or not the way we have encouraged/required the development of accessible sites in the past has been successful, and how we might improve the accessibility of the web in the future.

Rather than complaining about the possible failings of past, I believe after a decade of accessibility rules it is time explore options for the future: We need to enhance the acceptance of accessibility guidelines; raise the overall awareness of the need for improved web content accessibility; address the cost of access to information for assistive technology users; and, improve the ability of people with disabilities to use assistive technologies and standard user agents like browsers.

In the real world, most people now accept that the needs of people with disabilities should be accommodated in public transport and building design. When it comes to the web however, I am concerned that many still view accessibility through the lens of charity and not rights. Too often the needs of people with disabilities who use the web are dismissed and web site accessibility is considered an add-on, something to be done only when time and money permit. Rules alone are not enough. Attitudes and behaviour both also need to change.

SPEAKERS NOTES

I don’t have a verbatim transcript of the presentation; however my talk kept close to the following quite extensive speaker’s notes. Sorry there are so many words, but I can say a lot in 50 minutes.

SLIDE 1:
Many thanks for coming to this presentation.

We have had rules and laws relating to the accessibility of websites for about ten years. During this session I plan to look at the role they have played in encouraging, or requiring, developers and their clients to consider accessibility when developing sites.

While I will be talking in part about WCAG 2.0, I don’t propose to go over the POUR principals. I think we are all pretty familiar with them by now. Rather, I hope to highlight a few potential areas of concern and make a few suggestions for the future.

SLIDE 2:
There is a tendency to consider website accessibility primarily from the perspective of people with impaired vision. In particular, accessibility is often equated with how well a site and the information it contains can be accessed by someone who relies on a screen reader.

But of course, as we all know there are many other forms of disability and what works well with a screen reader may not always meet the needs of people with other disabilities.

SLIDE 3:
But first, to get a snap shot of the extent of different disabilities I have turned to the Disability, Ageing and Careers survey which the Australian Bureau of Statistics undertakes every five or so years. For this survey, a disability is defined as something that restricts one or more core activities, such as self-care, mobility and communication.

This Disability Survey found that about a third of the respondents indicated their disability related to sight, this amounts to about 7% of the total population. The degree of sight impairment is very varied, and by no means do all these people rely on assistive technologies such as screen readers or magnifiers to use the web.

The next largest category is physical with about 20% of the respondents, followed by hearing with 11%.

For a variety of reasons it appears that surveys like this under report the number of people with cognitive disabilities and learning disorders.

SLIDE 4:
So how many people have a cognitive or learning disorder?

Work done in 1999 by Jaye Johnson and Edith Cowen university in Western Australia provides some answers. Johnson surveyed year 12 students (the final year before Tertiary education) and found that intellectual disabilities, which included learning disorder, were by far the highest proportion of disabilities.

9% of students with disabilities reported visual loss as their major disability. Whereas, when we combine Intellectual disability and autism we get a figure of nearly 60%.

SLIDE 5:
Also, research by the Australian Learning Disabilities Association suggests that about 10 to 12% of the population of Australia have a learning disability, with 4% being severely affected.

I have made this brief mention of cognitive and learning disorders because even though it probably comprises the largest number of people with disabilities in our community they are often overlooked.

And, in my view there are not given sufficient consideration in Version 2 of the Web Content Accessibility Guidelines.

SLIDE 6:
During the last decade or so one of the most significant shifts in terms of accessibility has been the move from what could be basically described as a charity model, where favours are dispensed to those in needs, to the notion of social inclusion.

What do I mean by social inclusion?

In short, it is about having a society where all people feel valued, their differences are respected, and their basic needs are met so they can live in dignity. In essence, the opposite of exclusion, which sees people excluded from participating fully in the social, economic and cultural life of a community as a result of their difference, be it income, race, gender or abilities.

Although we like to rejoice in the notion that all ‘men are created equal with inalienable rights’, this hasn’t always been the case.

Let us not forget, not 200 years ago there was slavery in so called “civilised” countries like the US, the UK and yes Australia; a hundred years ago women didn’t have the right to vote; and just 50 years ago the Aboriginal people of Australia were not counted in the census and basically had no rights at all, including the freedom to move around the country and live where they wished.

So what is the point of this polemic rave you might be thinking?

In the real world, most of us no longer think that it is all right to own slaves or the right to vote, own property or move to another city should depend on a person’s gender or racial origin.

Similarly, I believe most people now accept that the needs of people with disabilities should be accommodated in public transport and building design. And, there is increasing awareness of the abilities of those who were often stigmatised as disabled in the past. There is a growing recognition of the distinct cultural and linguistic identity of the Deaf community, and a far greater appreciation of the special talents of many people with cognitive disabilities.

When it comes to the web however, I am concerned that many still view accessibility through the lens of charity and not rights. Too often the needs of people with disabilities who use the web are dismissed and web site accessibility is considered an add-on, something to be done only when time and money permit. Consequently, while rules prohibiting discrimination against people with disabilities are important, what I feel we fundamentally need are changes in attitude. I go into these ideas in more detail in the article “Social Inclusion and the Web” on my Blog

SLIDE 7:
A little more than 10 years ago the W3C introduced Version 1 of the Web Content Accessibility Guidelines. Australia, along with a number of other countries, now has laws that require websites to not discriminate against people with disabilities. In many cases, these regulations use the WCAG checkpoints as the benchmark for accessibility.

At about the same time, the US Access Board released the 1194 Web Standards that relate to amendments to Section 508 of the Rehabilitation Act. These Standards, along with the American with Disabilities Act and other Federal and State laws underpin the requirement for website accessibility in the US.

There is not a whole lot of difference between the Guidelines of WCAG 1.0, and the Standards of Section 508. Both focus primarily on using W3C technologies such as HTML appropriately. Section 508 however does make provision for the use of JavaScript, applets and other non-W3C formats.

Another significant difference between the situation in the US and that in Australia is that 508 relates to the procurement and use of information technologies by Federal Agencies, while in Australia there is no requirement for agencies to consider accessibility when purchasing products like Content Management Systems or authoring tools.

SLIDE 8:
The web has moved on a lot in the last 10 years, I don’t the remember details of what we were using the web for back in 1999, but a quick look at the most visited sites by Americans and Australians today gives us a bit of an idea what we are doing now.

SLIDE 9:
It’s hard to find reliable data about web usage, but I think the information provided by a company called Alexa probably provides a pretty good indication.

This list indicates how many of the top 100 most visited sites in Australia and the US are in different categories, like social networking, search and let us not forget porn. The largest category, are those sites concerned with the I.T. and Web industry, followed by social networking and then search. The number of porn sites was far few than I would have thought, perhaps because these sites and their users are good at covering their tracks.

I guess it would come as no surprise to hear that Google is the most visited site now.

SLIDE 10:
The Nielsen company recently compiled a list of the 100 most visited sites in January this year, and the results are much the same as those from Alexa.

This Treemap of the top 100 sites prepared by the BBC represents the Nielsen data. The largest categories being: Search, Media, Retail, Software and Social Network including video, blogs etc

For me, this information about web usage today highlights a few interesting things:

  • Our huge reliance on search sites and tools for locating resources on the web,
  • The explosion of social networking and sharing sites like Facebook, Twitter and Youtube.
  • Also, the amount of buying and selling that is going online today. Many sites now have an online payment system. And during the last 10 years ebay has grown from a small US business with a few employees and to a massive global enterprise with over 15 thousand workers.

SLIDE 11:
So, a lot more people are using the web for many more reasons than they did back at the start of the millennium. But, have than ten years of accessibility rules and regulations improved the overall accessibility of content on the web.

Anecdotally it seems that it is better, and when you look at specific sites it is often easy to seem improvement. But overall, is the content of the web more accessible? I don’t know, I still see many crummy sites.

When preparing this talk, I did a quick check of the accessibility of the most visited sites in Australia and the US.

SLIDE 12:
These are the seven most visited sites in Australia according to Alexa. No real surprises here: Google number one, followed by facebook and Youtube. Ebay comes in at 6 followed by NineMSN, a less than perfect site when it comes to accessibility.

I used the WAVE tool to test the home page and a couple of other pages from each site. I know using an automated tool to test just a few pages is a rather crude measure of accessibility, but it was quick.

As you can see, WAVE identified accessibility errors on all home pages, except for the Bing page. NineMSN was the worst, with 52 errors on the home page according to WAVE.

Also the home pages of all seven sites use JavaScript in some way or other. And at least 5 of the sites contain some non W3C content, usually Flash.

SLIDE 13:
Here are the results for the 7 most visited US sites.

Not really much different to what we saw with the Australian sites although a little more in the area of social networkings with both Facebook and Myspace making the top seven. Again, WAVE identified accessibility errors on most home pages and all the sites have JavaScript and nearly all contain some non-W3C content.

SLIDE 14:
Vegemite!

For those not familiar with this Australian delicacy: It’s a salty spread made from used brewer’s yeast that we all grew up on. According to the ads, it gave us vitality and could even solve teenage problems.

The true test of being an Australian is to be able to sing the vegemite song for “we love our vegemite, we all enjoy our vegemite, it puts a rose in every cheek.”

But even vegemite had to move with times.

SLIDE 15:
Don’t you just love the way everything is 2.0 nowadays.

As well as the “2.0” suffix, vegemite even managed to slip in the “i” prefix.

iSnack 2.0, a ‘great’ idea by Vegemite to show that “they get it”, if I might borrow an oft used phrase of the cool set.

SLIDE 16:
Even Government is going 2.0.

During the last year or so, the US and Australian governments, along with many others, have organised studies, camps and

taskforces to explore ways of using the new social networking and interactive web technologies. The aims are often noble and lofty:

  • To increase openness by making government information more widely available
  • And to encourage more active collaboration from people wishing to contribute to public life.

But I am sure many in this room will not be surprised, when I suggest some of the sexy web 2.0 interactive stuff is not very accessible; and some of it downright inaccessible.

SLIDE 17:
How governments around the world balance the potential of web 2.0 with the reality of making sure that these new ways of engaging with the community are available to all will be interesting.

Sadly, I don’t feel the “Government 2.0 Taskforce” in Australia really came to grips with this question, perhaps this is not surprising since it seems that no one with specialist knowledge in the area of accessibility was on the Taskforce Committee.

The Report of the Taskforce contains a number of significant and far reaching recommendations in regard to promoting transparency and greater engagement with the community. However I feel the Taskforce and its Report present a very narrow, technology-centric view of what is required when it comes to the adoption of Web 2.0. The report seems to assume all citizens who may wish to engage with the government are able-bodied, web-savvy, can read English and are both willing and able to use social networking tools.

Rather than arguing the case for social inclusion; the Report is more concerned with canvassing the various excuses for not addressing the issue of making sure all people, including those with disabilities, will be able to engage in the proposed Government 2.0 world.

The Report goes so far as to Recommend that when it comes to web 2.0, Government agencies should not need to comply with accessibility guidelines if they find complying all too difficult. For me this is a real worry.

SLIDE 18:
When it comes to social policy, the success of regulations or rules largely depends on three factors:

  1. The inherent justice or fairness of the rules
  2. An acceptance by the social group that there is a need for regulations
  3. And finally, willingness by the majority of those directly affected to comply with the regulations.

This willingness is often stimulated by incentives or sanctions. Or a combination of both – the so-called carrot and stick approach: Comply and you gain some form of explicit or implicit benefit; Fail to comply and you get whacked!

Over the years, I and other web accessibility advocates have offered the carrots of ‘doing the right thing‘, and the benefits of making sure your content is accessible to the largest number of people. At the same time, we have held out the stick of threatened prosecution for failing to comply.

But, as with most policies that require some change in behaviour, often at emotional and/or financial cost, the stick, while perhaps a useful adjunct in some circumstances, is often not a major determinant in changing human behaviour or attitudes.

SLIDE 19:
In 1901, Teddy Roosevelt helped himself to an old West African proverb, ‘Speak softly and carry a big stick‘, when it came to the exercise of political and judicial power. As many students of history will know, Roosevelt was able to use this approach with considerable effect in both local and international affairs.

However, I don’t think we could say this accurately reflects some more recent US approaches to international issues: Think of the George & Dick show, “Loud and big all the way”

Nor do I think it could be said to apply to legal attempts to enforce web accessibility in Australia and around the world.

SLIDE 20:
As far as I know, the first recorded case concerning website accessibility was in 2000 when Bruce Maguire complained that the site of the Sydney Olympic Games Organising Committee was not accessible. The case was successfully pursued by the Human Rights and Equal Opportunities Commission and soon became a cause celebre of accessibility advocates everywhere.

During the following years, there have been a number of other complaints in different countries over the inaccessibility of websites. While the threat of legal action in some cases has resulted in negotiated positive outcomes for the complainants, very few complaints have made it to court.

Not withstanding the fact that little has been established in the way of legal precedents, I and many others have been shouting very loudly for years about disability discrimination laws and the risks of prosecution.

But sadly, it appears to me that the actual stick of legal action has turned out to be more of a twig. A twig that is very rarely wield in anger.

I don’t wish to suggest that the softly-softly approach has necessarily been inappropriate. As much as I might have liked to see the purveyors of large inaccessible sites get a whack, I suspect such an approach could well have been counter-productive and undermined our overall desire to improve the accessibility of the web.

SLIDE 21:
In Australia, and other jurisdictions, the processes for ensuring website accessibility rules are complied with are largely complaint driven. That is, someone has to feel that that have been sufficiently discriminated against to complain, and then the regulatory authorities have to agree to support their complaint.

In reality this doesn’t happen very often.

Many times when I have been evaluating the accessibility and usability of websites with people who have disabilities, the participants have commented on the inaccessibility of some site or other they recently tried to use. However, when I ask if they have complained about it to anyone, the answer is nearly always NO!

And, what happens when complaints are made? Regulators, who most often have limited financial resources, are then faced with the prospect of taking on what are often very large businesses with very deep pockets when it comes to protecting their reputation in court. And then there is the real prospect of the action failing, a catastrophic outcome that could establish precedents for inaccessibility rather than accessibility.

So what is the net result? In my opinion the process of enforcing web accessibility through regulations is very difficult because:

  • First, many web developers and senior managers are not particularly sensitive to the issue of web accessibility.
  • And second, since they see so many sites that are inaccessible, where the failure to comply is without consequence, they just basically don’t feel the pressure to take it seriously.

SLIDE 22:
Over the last ten years, the web has brought huge benefits to many people, including many with disabilities. However we are now in danger of having a web where the gap between the haves and the have nots could become a chasm.

A web, where increasingly all the fruits will only be available to the cool and able bodied! That is, those who can afford the latest technologies and have the physical and mental capabilities to use them.

A web where the basics will be available to all, but only some can travel first class.

SLIDE 23:
The WCAG 1.0 of 1999 is not able to meet the needs of the web today, with its enhanced interactivity, and most strikingly, greater community engagement:

  • Social networking with Facebook and Youtube
  • Social bookmarking with Delicious and Digg
  • Tags and folksonomies, and
  • How can we forget twitter

We’ve all heard and answered these clarion calls for narcissism. Nowadays, everybody feels they have something to say, and nothing is going to stop them. But not everyone can!

Is the inaccessibility of many of these fancy new tools, Web 2.0’s Nemesis, extracting vergence from a few for the interactive, narcissistic excesses of the many?

SLIDE 24:
The reality is that there are many more ways to present and interact with web content today than there was 10 years ago. And this number will only increase in the future.

WCAG 1.0 was primarily about W3C technologies, particularly HTML and its variants. This was in one sense a form of technological prohibition that confined our notions of accessibility.

While this confinement provided some certainty and encouraged the appropriate use of W3C technologies, it could not stop the development and use of other technologies and more importantly provided no incentive for people to improve the accessibility of content using these non-W3C technologies.

And, in some cases, these other technologies may be more appropriate than HTML.

SLIDE 25:
A friend of mine, Judith has cerebral palsy; some of you may have seen her in the video “Wheeling in Second Life” which we made together a few years ago. Judith is unable to use her hands to control a mouse or use the keyboard. She is however very proficient at using computers with a headwand and does so nearly everyday for work and pleasure.

When it comes to online forms, it often takes Judith a long time to assemble the information and fill in the form. As a result, she generally prefers PDF forms rather than HTML forms because she can download them from the web, complete them in her own time and then go back online to submit them. For her, a good PDF form is much more accessible than a HTML form!

In my work, I have come across other situations where non-W3C formats have the potential to deliver content that is more accessible for the intended audience.

SLIDE 26:
For example, several years ago I reviewed some web-based kiosk material prepared for people who are homeless. The commissioning government agency recognised that a large proportion of their clients were functionally illiterate. However, the agency’s fear of breaching accessibility guidelines and thereby the (Australian) Disability Discrimination Act, resulted in them making a conscious decision not to use Flash, or any other non-text media, to present the information.

The solution, this short “Quick Guide”: 17 screens of words!

Another example, recently I had reason to look at online resources prepared for the vocational education sector in Australia. Most of the resources were interactive and contained Flash material.

Now for people with learning and cognitive disorders, a well made interactive resource that makes extensive use of non-text content is likely to be both more usable and more accessible. However, nearly 50% of the Flash material I examined would have been inaccessible to most screen reader users. And in many cases, the material trapped the cursor, thereby preventing anyone who was unable to use a mouse to get to the rest of the page.

When I asked some of the developers if they tried to make the Flash accessible, the answer was, “not often, not worth the effort, only if I am explicitly asked to”. The keen ones would go on to say they provided an alternative; but often this was not really an equivalent alternative to the Flash content as required by WCAG. For example rather than allowing someone to discover the answer to a problem through exploration or trial and error the alternative merely provided the answer.

SLIDE 27:
Killing Bambi, now there’s an idea!

For some, knocking Walt Disney is akin to mugging mother Teresa, even though he was known to hate kids and it is rumoured he had a torture chamber in the basement. But, what ever you think about Walt, killing Bambi is certainly bad taste.

SLIDE 28:
I won’t let that stop me.

Here we have a screen shot of the web page for ordering a DVD of the Bambi movie: At the top there is the main navigation, and down one side lots of links, for example, under the heading Categories there are links to things like Family Feature Films, Disney Classics, Disney Vaults, and then there are links to different formats etc. In the centre is the main panel with information about Bambi: “The forest comes alive with Bambi, the critically acclaimed coming-of-age story that has entertained generations of fans. This grand adventure is full of humour, heart and the most beloved characters of all time…

Now is that not wholesome and cute? But what happens if I turn off Flash?

SLIDE 29:
Oh dear, no navigation!

I should add at this stage, that when Flash is supported and the page is accessed with a screen reader, each of the navigation items is identified with the word “button”. For example, Categories: button, button, button, button and button. Format, button, button, button and so on.

And, what about the use of images?

SLIDE 30:
Well that’s very useful, no navigation and now no content.

But since I used a tool to only turn off inline image, we do know it is about Bambi, courtesy of a background image. Also, the content about the forest coming alive with Bambi and the most beloved characters of all time which appears to have disappeared is actually HTML and can be read by a screen reader: Just a small problem of white on white.

But wait, not all is lost…

SLIDE 31:
See, we have a text alternative for one of the images, telling us this is the official Bambi DVD site, beware those unofficial sites.

And, as you can see, the headings use H elements.

No seriously, enough of this frivolity. I am not trying to suggest we shouldn’t use images, or JavaScript or Flash, although I am NOT sure that Flash for navigation is such a great idea.

There are sites that use these technologies in a way that is accessible, and sometimes Flash or JavaScript can enhance the accessibility of a site for the intended audience. What I am trying to suggest is that perhaps trying to discourage or prohibit the use of different technologies might not be the best way to go. I mean to say, who are we to try and take on the power of Walt and Bambi?

SLIDE 32:
The introduction of WCAG 2 at the end of 2008 offered a new approach. WCAG 2.0 is not concerned with the technology used, but
how it is used. Of course, as with many things that come out of the W3C, if you can say it in a few words, why not use 100 and the bigger and more specialised the better!

I would like to make it clear however, that I am a big fan of the W3C and the WAI. Even though I sometimes criticise them and WCAG a bit, I think they are great and applaud their work, but writing in plain English is not one of their strong points.

One significant difference with WCAG 1 is that the WCAG 2.0 Guidelines and Success Criteria do not mention HTML and do not discriminate in favour or against any particular web content technologies. That is left up to others.

SLIDE 33
To help make this decision, WCAG 2 introduced the concept of “accessibility support”, and for a technology to be considered accessibility supported, it must meet two basic conditions:

  1. First, the way a web content technology such Flash or HTML is used must work with assistive technologies.
  2. Second, the user agents such as browsers and Readers, which are required to render the content, must also accessible and must not discriminate against people with disabilities in terms of availability and price.

SLIDE 34:
Of course, this raises the very interesting question of who decides what technologies can be considered accessibility supported. The W3C primarily hand this responsibility on to the authors of web sites, while at the same time recognising they probably don’t have the ability to make a decision:

“Individual authors will not usually be able to do all of the testing necessary to determine which ways of using which Web technologies are actually supported by which versions of assistive technologies and user agents.”

In reality, I am sure that the desire for consistency and certainty will mean that the various government agencies and other organisations, which are concerned with issues of discrimination in different countries, will be the ones who decide what technologies can be considered accessibility supported.

And, when it comes to deciding which assistive technologies should be able to support content, the WCAG Working Group handed the decision over to, well who knows who.

In my view, the failure to provide clear guidance in regard to these issues is one of the most significant failings of WCAG 2.0 and it places web accessibility at the crossroads.

SLIDE 35:
For, as countries move to endorse WCAG 2.0 they are faced with the issue of how to deal with the many different web content technologies and formats that are in use to day. Do they adopt the WCAG 1.0 approach of basically saying only W3C formats like HTML can be relied on to present content? Or, do they embrace the WCAG 2.0 notion of technological neutrality, and concentrate on how the technology is used rather then the technology itself?

This is a very complicated question, with many competing arguments. The simple solution is to stick with what you already know. This seems to be the approach adopted by New Zealand, which in March 2009 became one of the first countries to adopt WCAG 2.0.

SLIDE 36:
Apart from some of the technical changes relating to the use of HTML, as far as I can see, the New Zealand accessibility standards of today are very little different to those of 10 years ago.

If you use JavaScript and other programmatic objects, the pages or page elements must not rely on them for presentation or functionality – pretty much the same as WCAG 1.0 Checkpoint 6.3 (among others). And, if you use non-W3C formats such as Flash, PDF, Word and even RTF, you have to also provide the content in HTML; much like WCAG 1, Guideline 11 and specifically Checkpoint 11.4.

In essence, this is a prohibition model and provides little or no encouragement to improve the accessibility of non-W3C material.

SLIDE 37:
The New Zealand model is one simple solution to the problem of how to ensure the accessibility of content produced with new technologies. Another simple, or should that be simplistic, solution is to assert that it is all the fault of the regulators: If they prosecuted a few more people then the problem would be solved. In essence take out the big stick and use it to beat developers and manager into complying.

Sorry, but I don’t buy simple solutions to complex problems, particularly ones that involve human behaviour.

SLIDE 38:
In my view, web content accessibility regulations need to cater for the range of technologies that are currently being used, and those that may be used in the future. I am concerned that a continuation of the current (WCAG 1.0) practice of only considering W3C technologies accessible will:

  • Provide little incentive for developers to improve the accessibility of web content that uses non-W3C formats like JavaScript and PDF.
  • And, in the process, reduce the pressure on the producers of non-W3C technologies to improve the accessibility of their products.
  • Furthermore, if these products are hard to make accessible and most developers don’t bother to use the few accessibility features that are available, where is the incentive for the manufacturers of assistive technologies to improve the capabilities of what they produce?
  • Finally, when it comes to community acceptance of web accessibility, I am afraid that as more and more high-traffic sites use inaccessible non-W3C technologies without appropriate alternatives, web developers will increasingly question the value of making their sites accessible.

Rather than prohibiting the use of specific technologies, I think it is time to try something different. And so I would now like to sketch out a few ideas or suggestions.

SLIDE 39:
As a start, I think the New Zealand minimalist WCAG model is not appropriate. I believe Australia and other countries, that use WCAG as their reference point for accessibility, should adopt WCAG 2.0 at level AA. And, I believe they should embrace the notion of technological neutrality.

The Australian Government recently endorsed WCAG 2 and announced they would progressively move to Level AA over the next four years. But the question of which technologies will be considered acceptable is still to be decided and I desperately hope we don’t follow the approach of our Tasman cousins.

I believe the key question should be: Does the use of a web technology comply with the guiding Principles and Guidelines of WCAG 2.0?

SLIDE 40:
Very often discussion about compliance with WCAG 2.0 is solely in terms of the Success Criteria and their associated Techniques. That is: Are these specific techniques satisfied on a web page? If they are, then the page complies with the related Success Criteria. And if all the Success Criteria are complied with, then the page is considered accessible.

From my experience very few people in the industry understand the difference between ‘normative’ Success Criteria and ‘informative’ Techniques. Just the other day, a very large organisation told me that they hadn’t gone for Level AA because the developer had told them that they would have to meet over 700 W3C accessibility rules.

Of course this is not correct, but many developers are looking for hard and fast rules relating to HTML such as “use header elements”, as was the case with WCAG 1, and they see these rules in the Techniques document and so believe they must all be met.

Developers, and their clients, often appear to be mainly concerned with ticking off a few checkpoints rather than making sure something is accessible. I believe, when it comes to determining if a site is accessible, a more comprehensive and satisfactory approach is contained in the five Conformance Requirements specified in the WCAG 2.0 document, but unfortunately it seems to me that most developers are not aware of them.

SLIDE 41:
As I have indicated, much of the discussion concerning the implementation WCAG 2.0 often revolves around whether or not a particular content technology can be considered to be accessible. And, there is pressure on regulators to indicate which technologies they believe are accessibility supported.

Rather than attempting to nominate accessible web content technologies, I feel it might be more useful for regulators to identify those assistive technologies (and technology versions) that they believe need to be able to access web content. Obviously, such a list would need to be regularly up dated as assistive technologies improve and new ones are developed.

For example, lets imagine for a moment, that the only requirement is for all web content to be accessible with JAWS Versions 8 plus. Then if a particular use of PDF, or Flash, or HTML for that matter, can be successfully used with JAWS 8, 9, 10 etc it would be considered “accessibility supported”.

Now of course this is a very simplistic example and there would probably be many more nominated assistive technologies. But, such an approach would give certainty to clients, encourage developers to improve the accessibility of content technologies, and just as importantly, it would be easily testable.

SLIDE 42:
I feel it would also be useful for developers to prepare an accessibility compliance statement as suggested in WCAG 2.0. The statement doesn’t have to be anything fancy, nor should it require the use of an accessibility specialist. All the statement needs to do is:

  • Indicate the pages, site or application it applies to
  • The WCAG level complied with
  • The technologies that are relied upon, that is the ones for which there is no alternative
  • The technologies used but not relied up, that is those that are used for which an alternative is provided
  • The author/owner of the site
  • And, the date of Statement

I can see it might be difficult to have a requirement for Compliance Statements at a national or government level, but I think it is very possible for this to be a requirement at the industry sector level or by individual businesses.

One big benefit of compliance statements is that they provide something concrete that the site can be measured against should a complaint be made. Also, requiring an accessibility statement will help return responsibility for accessibility to the wider web community.

SLIDE 43:
The Web as we know it, is 16 years young, still to reach voting age in Australia. We all know there is a lot of inaccessible junk out there, but I feel it is better to spend time improving stuff for the future rather than worrying about the crappy junk of the past.

In my view, there should be a full exemption from complying with either WCAG 1.0 or WCAG 2.0 for all materials produced before 1 January 2009, on the condition that the owners of those materials provide a description of the materials and what they contain. I know many will disagree with this approach since it will give tacit approval to a bunch of inaccessible material, much of it old. However, I don’t think it is realistic to assume that much of this material will be improved what ever the regulators say.

If material has any ongoing value is it likely to be updated or migrated to a new or revised site at sometime in the future. And when this happens, I believe there should be a requirement for the material to comply with WCAG 2.0.

In other words, we say to content owners, if you don’t need it get rid of it and if you want to keep it, make it accessible.

SLIDE 44:
We know a well made site can be used by people with disabilities, and there is a tendency to assume everyone knows this. But this is not the case.

It is amazing how many developers and people with responsibility for websites in large organisations really have no idea. In my experience, hostility to web accessibility guidelines often stems from the fact that people just don’t see the point. They just can’t believe someone who is blind, for example, can use a computer let alone the web

A quick digression to help illustrate this point: A few years I took a client to the Royal Blind Society in Sydney so that they could see how people with different vision impairments use their site. Anyway, as it happens we couldn’t get onto the web – some problem with the proxy settings or something or other. So we rang tech support. And in due course a young man in a white shirt turned up, an experience the client was very familiar with.

But here is the difference; the tech support man was blind. Using information he got from a Braille note machine, the young man re-configured the settings and had us online in no time at all. And what about the client – well their eyes were out on stalks, just could not believe it!

For some years I have been running accessibility workshops. Now obviously these workshops are more likely to appeal to people who are sympathetic to the notion of accessibility. Five years ago, when I asked if anyone had seen a screen reader in use, I would be lucky if one in twenty had. Two years ago, it was over 30%, but none had seen Braille being used. And so I decided to make a video, utilising the skills of my pre-web life when I worked in the film and television industry for many years.

SLIDE 45:
I made “Refreshable Braille and the Web” with a friend Bruce Maguire, who I am sure some of you know. In the video he demonstrates the machine and shows how he goes about buying a book from Amazon. The video is available on YouTube and DotSub, where it has been captioned and translated by others into Italian and Spanish.

I have found videos to be a great awareness raising tool and I regularly use them in my workshops. But more importantly, I have found they are a great way to break down the resistance to accessibility by some clients. With many clients, and developers for that matter, a simple short video like this one, or “Wheeling in Second Life” which I mentioned earlier, can be more effective than many thousands of words!

The number of videos on the web showing different assistive technologies in use is growing all the time and I think this is great. I am hoping to make a few more myself in the future as time permits.

But video is only one of many possible ways we can raise awareness and provide information about accessibility. The WAI documents, such as the Business Case overview, are another great awareness raising resource which I refer people to.

SLIDE 46:
There is a growing need for more information and resources for the web community about what is required to produce accessible material using different content formats.

The W3C clearly have a very important role to play in this, but it should not be left up to them alone. Regulators and the web industry as a whole could do more in disseminating information about how to make accessible sites. I should acknowledge the considerable role many individuals and organisations have played in this regard over the last few years, but much more needs to be done.

This will be increasingly important, not only because new content technologies are appearing all the time, but also because we are constantly developing new ways of doing things, for example not so many years ago no one had ever heard of image-replacement or Ajax. The underlying technologies were always there, it’s just that now they are being combined and used in new ways.

SLIDE 47:
In the rush to explore and introduce new ways of providing online content, the cost of ensuring access to this content by all web users is often overlooked.

Although, as we all know, the price of computers falls by the minute, there are still millions of people who can’t afford to keep up with the latest and greatest in this rapidly changing environment. And, let us not forget, that within our communities, people with disabilities are often among those with the least financial resources.

There is little point in introducing a fantastic online resource for people with cognitive limitations, for example, if it doesn’t run on standard, commonly used user platforms. And, when it comes to assistive technologies like screen readers, vendors are bringing out new versions all the time in order to keep up with the changing web.

Some how we need to avoid the costs of technological advances becoming an entrenched barrier to accessibility. In this regard, I am very interested in the whole NVDA movement and in the way outside financial support have allowed them to focus on improving access to new developments like ARIA.

While NVDA might not be as comprehensive as many of the commercial screen readers, it is free and relatively easy to use, and so offers a real alternative to people around the world who rely on screen readers to access the web.

The accessibility problems associated with image CAPTCHAs are well known, and this has stimulated a third-party volunteer solution called Solana. While community engagement and social problem solving is great, should access to some areas of the web for people with disabilities be dependent on the good will of a few? Might, this not be another variant of the charity model I referred to earlier?

SLIDE 48:
When it comes to assistive technologies, we often assume that all the people who rely on them to access the web are highly skilled in their use. I am not sure why we make this assumption, because it is not one we tend to make with other web technologies.

In a recent WebAIM survey of screen reader users, about 60% of respondents described themselves as having advanced computer skills. And when it came to screen reader proficiency, 50% described their proficiency as intermediate or beginner. (We need to bear in mind that the respondents to this survey are likely to be at the more aware or geeky screen reader users.) When it came to learning how to use screen readers, nearly three quarters said they were self taught.

So finally, in addition to taking a technologically neutral approach to WCAG 2 and increasing the ability of web developers to make accessible content, in my view, assistive technology users also need to be provided with the resources to help them improve their skills in using the technologies they require to access content in a variety of formats.

SLIDE 49:
I am fearful if we don’t take a more active approach to accessibility and rely just on rules and regulations alone, the web will increasingly become a communication medium that only an able-bodied, tech-literate elite will be able to participate in.

Thank you. Here are my contact details.

Any questions or comments?

WCAG 2 – Don’t Panic

After nearly a year of deliberation, the Australian government has finally decided to move from using Web Content Accessibility Guidelines 1.0 (WCAG 1.0) to WCAG 2.0 as the benchmark for website accessibility. On Wednesday February 24, The Australian Government Information Management Office (AGIMO) announced:

“Government agencies will transition to WCAG 2.0 over a four year period, reaching level Single A within two years, and Double A within four years. A Transition Strategy will outline the process for implementation, and will address scope and inclusion issues. The Transition Strategy will be made available on the Web Publishing Guide in July 2010.”

Almost immediately half truths and wild rumors began to circulate around the web. I heard a report of one developer saying, WCAG 2.0 Double A compliance was almost impossible because it meant that you had to meet over 700 checkpoints. This is incorrect.

And so, following a little prompting by friends, I decided to write this very brief overview of WCAG 2.0.

But first, although the announcement relates to government websites, it is extremely likely that the WCAG 2.0 requirements will extend to all web pages developed by organizations in Australia or placed on a web server in Australia.

Differences between WCAG 1.0 and WCAG 2.0

One major difference between WCAG 1.0 and WCAG 2.0 is that while WCAG 1.0 was primarily concerned with HTML, the WCAG 2.0 Guidelines and Success Criteria do not refer to HTML or any other web content technology.

Instead, WCAG 2.0 introduced the concept of “accessibility-support”. This means that for a web content technology (e.g. HTML, Flash, JavaScript etc) to qualify as accessible it must meet two basic requirements:

First, the way a particular web content technology is used must be supported by assistive technologies such as screen readers and switching devices.

Second, users must be able to obtain user agents (e.g. browsers and plugins) for the web content technology. These user agents have to have to be accessible and work with the assistive technologies, and the availability should not discriminate against people with disabilities.

WCAG 2.0 is not concerned with the technology used, but how you use it. However, this doesn’t mean you can use any technology you like. It is going to be up to authorities in Australia, probably AGIMO and the Australian Human Rights Commission, to decide which technologies they will consider accessibility-supported and under what circumstances. For example, will they decide to accept JavaScript, or PDF, or PDF forms as accessible formats? We may not get the answers to these questions until the Transition Strategy is released in July.

Structure of WCAG 2.0

The structure of WCAG 2.0 starts with four basic principles of web accessibility:

  1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive with at least one of their senses.
  2. Operable – Users must be able to operate the interface and it can’t require interactions that the user can not perform.
  3. Understandable – Users must be able to understand the information as well as the operation of the user interface.
  4. Robust – Content must be robust enough so that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Within these four Principles there are 12 Guidelines and each Guideline contains a number of Success Criteria. All together, there are 61 Success Criteria and each Criterion is given one of three levels of conformance, A, AA or AAA. It should be noted, the WCAG 2.0 Success Criteria are not the same as the Checkpoints in WCAG 1.0.

WCAG Documents

The core W3C Web Content Accessibility Guidelines 2.0 is a “normative” document which contains the Principles, Guidelines and Success Criteria. These are basically the rules.

The Guidelines provide the requirements for making content more accessible to users with different disabilities, but in themselves are not really testable. Success Criteria, on the other hand, are designed to be testable, either by machines or humans, and are usually presented as testable statements. Success Criteria can be used for things like design specifications and for conformance testing to see if a site has satisfied contractual agreements.

The “normative” document containing Guidelines and Success Criteria is supported by “informative” documents, including Understanding WCAG 2.0 and How to Meet WCAG 2.0. The How to Meet document contains a number of suggested techniques for complying with each Success Criterion, but developers do not need to comply with all the suggested techniques, just those that are required to satisfy the Success Criterion. For example, when it comes to identifying a form input, you might use the ‘label’ element with the ‘for’ attribute (Technique H44) or a ‘title’ attribute for the input element (Technique H65) depending on the circumstances, but it is not likely you will use both.

It will be important for developers to understand the relationship between Principles, Guidelines and Success Criteria. But the How to Meet document is where you will find practical advice and many very useful examples about how to make things accessible.

WCAG 2.0 Conformance Requirements

The W3C provides five Conformance Requirements that must be met in order for content to be classified as ‘conforming’ to WCAG 2.

  1. All the information or content on a page must meet one of the Success Criteria levels. For example, is it Level A or Level AA? Or has an appropriate complying alternative been provided. NB: No conformance is possible if all the content does not fully satisfy Level A
  2. The whole page has to comply. You can’t just exclude the parts of a page that might have content that doesn’t comply. However, you can use non-complying content so long as an alternative is provided and it doesn’t interfere with the page (see point 5).
  3. Where a page is part of a process, e.g. purchasing a ticket, all pages or steps in the process must conform at the specified Success Criterion Level.
  4. Only “accessibility supported ways of using technologies” can be relied on and where this is not possible an alternative that is accessibility supported should be provided.
  5. Technologies that are not accessibility supported can be used, as long as all the information is also available using technologies that are supported AND the non-accessibility-supported material on the page does not interfere with the ability of users to use the rest of the page, for example it doesn’t trap the cursor, or users can control audio content.

WCAG 2.0 – No Need to Panic

Finally, although the WCAG 2.0 documents contain a lot of words, which some might find a little confusing, and there are a few new requirements, most experienced web developers won’t find moving from WCAG 1 to WCAG 2 difficult. Furthermore, WCAG 2 offers greater flexibility and some real benefits for designers and developers, for example a more practical approach to the use of colours and the mark-up of forms.

More information:

WCAG 2.0 Guidelines (W3C)
http://www.w3.org/WAI/GL/WCAG20/

Understanding Accessibility Support (WAI)

WCAG 2.0 and Accessibility Supported (Roger Hudson)

Comparison of WCAG 1.0 Checkpoints to WCAG 2.0 (WAI)

Migrating from WCAG 1.0 to WCAG 2.0 (WIPA/Roger Hudson)

NOTE: I will be looking at how to comply with the key Single A and Double A Success Criteria during the WCAG 2.0 in Depth workshops in April and May.

Australia goes WCAG 2

On Tuesday 23 February the Minister for Finance, Lindsay Tanner, announced the Australian Government had endorsed WCAG 2.0.

The press release by Minister Tanner contained few details, but said all government websites would need to comply with WCAG 2.0 by 2015.

“These new standards will improve the ability of people with a broad range of disabilities to take up those opportunities and engage with the Government via the Internet.”

Mr Bill Shorten, Parliamentary Secretary of Disabilities, reminded us that people with disabilities still face barriers that stop them from participating in many areas including work and education. He also said unequal access to information would reinforce the 2nd class status of people with disability within Australia. Mr Shorten supported the move from WCAG 1.0 to WCAG 2.0.

“This initiative will help ensure that people with disability are not left behind by the rapid growth of the Internet.”

On Wednesday 24, The Australian Government Information Management Office (AGIMO) provided the following additional information:

“Government agencies will transition to WCAG 2.0 over a four year period, reaching level Single A within two years, and Double A within four years. A Transition Strategy will outline the process for implementation, and will address scope and inclusion issues. The Transition Strategy will be made available on the Web Publishing Guide in July 2010.

Agencies are reminded that it is still a requirement to publish an alternative to all PDF documents (preference for HTML or RTF). Advice on the accessibility support of PDF documents will be made available at the conclusion of the PDF Accessibility Review Project, due early 2010.”

The Transition Strategy, which is to be released in July, will be critical for at this stage we don’t know which technologies will be considered “accessibility supported” within the meaning of WCAG 2.0. In other words, when moving to WCAG 2.0, will it be acceptable to use accessible JavaScript or PDF, for example, without the need to provide an equivalent HTML (or RTF) alternative?

It should be noted, that although the press release refers directly to government websites, the Australian Disability Discrimination Commissioner has strongly supported the move so it seems very likely that the Human Rights Commission will extend the requirement to all websites.

I think the move to adopting WCAG 2.0 is great and overdue. It has the potential bring significant benefits to web developers and their clients as well as web users with disabilities, including those who rely on assistive technologies.

For more information:
WCAG 2.0 Guidelines (W3C)

WCAG 2.0 and Accessibility Supported (Roger Hudson)

Understanding Accessibility Support (WAI)

NOTE: I will be looking at how to comply with the key Single A and Double A Success Criteria during the WCAG 2.0 in Depth workshops in April and May.

Government 2.0 Draft Report and Accessibility

While there are many things to praise in the Government 2.0 Taskforce Draft Report, ‘Engage: Getting on with Government 2.0‘, sadly I find it very light-on when it comes to the whole issue of social inclusion for people with disabilities.

How governments around the world balance the potential of web 2.0 with the reality of making sure these new ways of engaging with the community are available to all, will be interesting. After several months work and several million dollars, the Draft Report of the Taskforce unfortunately does not offer us any new insights into this question, and if anything steps back from the notion that universal access to web content should be a right, and not a privilege. Perhaps this is not surprising since it seems that no one with specialist knowledge in the area of accessibility was on the Taskforce.

The Draft Report contains many nice words about the importance of open government and how we need to do more to ensure that agencies share information. It also talks about the need to simplify copyright and the use of Creative Commons to allow others to remix and reuse government information in different ways. I find little to argue with in these overall aims.

The Draft Report also promotes the use of ‘Web 2.0’ social networking tools by the Public Service as a way of enhancing greater engagement with the community, quote:

“‘Government 2.0’ may be understood as the application of tools and approaches associated with collaborative web or ‘Web 2.0’ as it has been dubbed. These tools are potentially transformative of the way governments operate.”

I have no argument with the notion that the use of social networking tools can bring benefits in terms of greater engagement and collaboration by the people who use these tools. In fact, I believe some of the tools mentioned in the Draft Report can bring real accessibility gains to people who may otherwise be socially isolated as the result of specific physical, cognitive or behavioural disorders.

I am concerned however, that the Taskforce does not appear to have identified how many people in Australia actually use these web 2.0 tools. I would have thought that this would be essential if you are going to advocate tools and approaches that have the potential to transform the way governments operate.

During September 2008, I did a quick survey of 90 people to gain some insights into the Use of Web 2.0 Tools. I found significant differences in both how much the tools were used and how they were used by different sectors of the community. For example, the web 2.0 tools considered were used on average by 84% of web evangelist (surveyed at a Web Standards Group meeting), whereas 43% of media workers and only 25% of teachers surveyed used the tools. Now, I don’t pretend for a moment that the results of this survey give us anymore than a glimpse at the use of some social networking tools by 90 people in late 2008.

However, given that the Taskforce mandate was to advise and assist the Government to make government material more accessible and usable by the general community, I was expecting to see in the report some indication of the overall use of the suggested web 2.0 tools by different sections of the Australian community. In particular, when it comes to the issue of social inclusion, I would like to know if the Taskforce considered the following questions:

  • How many people who come from non-English speaking backgrounds, or who are unable to read English, use the web and web 2.0 tools?
  • What percentage of the people who live in regional Australia use web 2.0 tools?
  • What percentage of the older section of the community use web 2.0 tools?
  • Do web 2.0 tools pose any accessibility problems for people with disabilities who rely on assistive technologies? The 2009 WebAim “Screen Reader User Survey” offers some useful insights into this question. Of the people who responded to the WebAim survey, 25% found social media websites generally inaccessible.

Accessibility concerns

I will now turn to the specific issue of accessibility, as defined by the W3C Web Accessibility Initiative:

“Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web”

The Australian Government 2.0 Draft Report is large, 159 pages, and in those pages there are numerous references to many Acts of Commonwealth and State parliaments concerning a wide range of issues including; privacy; FOI; use of data; financial management; defence and security. One Act that doesn’t get a mention is the Disability Discrimination Act (1992), probably the most important act in Australia when it comes to protecting the rights of the disabled.

Of the 159 pages in the report, only a few are concerned with the accessibility of web 2.0 tools and the overall attitude is probably best summed up by this quote from the report:

“In many instances the application of full accessibility compliance can result in major delays, abandoning of initiatives or a severe weakening in functionality. In the public sector compliance is mandated, if compliance cannot be met then the project cannot proceed. The result is that access is denied for everyone.”

What are the ‘many instances’ where full compliance can result in major delays? No examples are provided in the report. However, one of the Government 2.0 Taskforce blogs, “Accessibility for all or none?” is illuminating in this regard. The blog describes how one government department did not publish 300 submissions they had received because they did not have the resources to convert them into HTML. The post goes onto say:

“The result of meeting the mandate was that access to substantial, valuable content was eliminated. I think the intent of the rules is to provide access for everyone.

Is this acceptable? If accessibility requirements cannot be met, does that mean that content or systems cannot go on-line?”

To me the rhetorical questions at the end of the above quote come perilously close to “dog whistling” that will give succour to those who labour under the misconception that accessibility is all too difficult and/or too expensive.

Of course making accessible alternatives for 300 submissions is going to cost money. But, surely when a government department requests submissions, the pertinent question to ask is, why didn’t the department factor into the overall process and budget for the project how they were going to make the submission accessible? I have no doubt this same unnamed department would save money when designing a new office building if, for example, they tell the architects and builders not to worry about things like toilets for the disabled or wheelchair access. It really comes down to the simple question of whether or not we believe access to web content by people with disabilities should be a right, or some form of charity to be dispensed only when time and money permits (see Social Inclusion for the Web).

The Government 2.0 Draft Report contains many examples of how web 2.0 can enable connections and collaborations of all kinds. For example:

“Thus, the social networking website Facebook has facilitated and enriched communication between people within social networks. Meetup.com, where people propose meetings, anywhere and for anything, has facilitated all sorts of get togethers of people with common interests and passions. And the internet ‘ideas market’ Innocentive has brought together those with technical problems to solve and those who can solve them.”

Many of the examples provided in the report, including all three in the previous quote, fail to fully comply with either version 1 or version 2 of the Web Content Accessibility Guidelines. In some cases they are likely to be inaccessible to many assistive technology users, not because it would have been difficult to make them accessible, but because nobody bothered to do it. For example, the “Innocentive” site uses a CAPTCHA image for registration without providing an alternative in another modality. (In the previously mentioned “Screen Reader User Survey” CAPTCHA was the item that most participants found problematic, and yet many web 2.0 tools use CAPTCHA.)

Sure coming to grips with the accessibility demands of some new technologies will be difficult, however the work of the Taskforce and the Draft Report do not appear to offer any suggestions or advice in this regard. I would have thought that with a budget, which I think was $2.4 million, spending a small a proportion on researching CAPTCHA and possible alternatives would have been a good investment with long term benefits for all government agencies and the web community as a whole.

The accessibility section of the Draft Report does contain some generalised statements about the need for cultural change and compliance with WCAG. However, these are somewhat undermined by the Taskforce’s failure to unequivocally advise government agencies to comply with the Disability Discrimination Act and the requirements of AGIMO when it comes to web content. Rather the report suggests:

“Freedom for agencies to choose non-accessible tools after careful consideration and always with the aim of maximum accessibility compliance. This enables agencies to deliver innovative engagement projects while maximising accessibility in the circumstances and providing alternative options for accessibility. For example, an agency may wish to use Facebook as tool as part of a consultation process, which would in many cases make good sense. However, the agency would need to ensure that it was not limiting the potential for citizens to participate in the consultation because of accessibility issues associated with the tool;”

Well at first glance that seems fine, but:

  • What constitutes “careful consideration” – a quick chat with colleagues by the water cooler or commissioning someone with specialist knowledge to thoroughly research the issue?
  • How can you choose a non-accessible tool “always with the aim of maximum accessibility compliance”?
  • What “circumstances” and what “options for alternatives” should be considered when “maximising accessibility”?
  • And, if you don’t make material accessible are you not limiting the potential for some citizens to participate?

In my opinion, all these issues could be adequately addressed by the Taskforce recommending agencies comply with the requirements of WCAG 2.0 with appropriate technologies declared “accessibility supported.”

In Recommendation 13 – Accessibility, the Taskforce recommends:

“Agency compliance with the Worldwide Web Consortium’s Web Content Accessibility Guidelines (WCAG) as the minimum accessibility level for all online community engagement and online PSI [Public Sector Information] provision is required.”

Once again this all seems fine, but in the next point the Taskforce steps back from fully supporting the need for accessible web content. Quote:

“Where an agency is considering a project where strict compliance with WCAG accessibility guidelines would unacceptably delay or prevent a project from proceeding, AGIMO will provide guidance on options to facilitate maximum access for people with disabilities;

In this case projects should only proceed with an online statement explaining site accessibility, together with an outline of where and why it does not meet a specific WCAG guideline, and what alternative options for accessible access were considered or are provided and plans for future compliance.”

More weasel words: What is “unacceptable delay”? When push comes to shove, under this recommendation, would an agency have to do anything more than “consider” an alternative option and indicate that they plan to comply at some undetermined time in the future?

A quick aside on the question of what is acceptable in terms of time: I couldn’t help noticing that the audio from the Government 2.0 Roadshows of last August still don’t appear to have transcripts, even though they were promised at the time. The “Vox Pop 2.0 Learning Journey” blog makes for interesting reading in this regard.

Now, as many will know, the failure to supply a text alternative is in breach of WCAG 1.0 and WCAG 2.0 as well as AGIMO guidelines, but I am not sure if 6 months would be considered an acceptable or unacceptable amount of time to comply with these requirements. I also notice that the Vox Pop 2.0 blog asked for people to help generate the transcripts, in part as an example of “crowdsourcing and collaboration”. Wishful thinking or deliberate obfuscation, I leave it up to you to decide. Whatever you decide, I am not sure it is appropriate for a government taskforce to leave meeting its obligations in the area of web content accessibility up to the charity of others.

In conclusion, I feel the Draft Report presents a very narrow, technology-centric view of what is required. The report seems to assume all citizens who may wish to engage with the government are able-bodied, web-savvy, can read English and are both willing and able to use social networking tools.

Rather than arguing the case for social inclusion; the report is more concerned with canvassing the various excuses and discounts for not addressing the issue of making sure all people, including those with disabilities, will be able to engage in the proposed Government 2.0 world.

NOTE: I will be examining issues involved in balancing the use of new technologies with accessibility requirements during the WCAG 2.0 in Depth workshops in April and May.