Author Archives: Roger Hudson

Social Inclusion for the Web

by
,
2

We no longer think it is acceptable to discriminate against people on grounds of gender or race and, as a community, we expect provision to be made for people with disabilities in public transport and building design. However, when it comes to making sure web content is accessible to all users of the web, including people with disabilities, some designers, developers and clients just ‘don’t get it’, to borrow a phrase popular with the geekerati.

We like to rejoice in the notion that all ‘men are created equal with inalienable rights’, or ‘from each according to their ability, to each according to their needs’, to take a more Marxist approach, however this hasn’t always been the case.

Let us not forget, Australian women only won the right to vote at the beginning of the twentieth century. And for the next 65 years, when it came to employment, there was no such thing as equal pay for equal work for women and those who worked for the Public Service had to resign when they got married. Before the 1967 referendum, Aboriginal men and women had almost no rights, they weren’t included in the census and didn’t have the freedom to move around the country or live where they wished.

In these examples, sections of the Australian community were either excluded from full participation in society or their participation depended on the beneficence of those in power, who for most part were white men of property.

Of course, the situation in Australia is a lot better today. We no longer have a “white Australia” policy and there are various anti-discrimination laws. This is not to suggest that there is no racism in Australia or women have full equality in employment, for the introduction of laws alone is not enough; community attitudes also have to change.

During the last decade or so, social policies relating to people with disabilities in many countries have changed significantly. There has been a shift from what could be basically described as a charity model, where government and non-government organisations ‘helped’ those identified as in need, towards 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.

It’s the opposite of exclusion, where people are excluded from participating fully in the social, economic and cultural life of a community as a result of their difference, be it in their income, race, gender or abilities.

As we know, in the past, society didn’t fully embrace the idea that people of a different gender or colour should have equal rights, and this same attitude of exclusion also bore down on those in the community who looked or behaved differently. For a child with cerebral palsy or an adult who was blind, access to education, information, transport – the everyday things of life – was not an inalienable right, but depended to a large extent on the charity of others. This colonialist model saw us; the able bodied with enlightenment and of course self-declared physical and mental abilities, bestowing gifts and privileges on them; the disabled.

When it comes to disabilities, progress towards more socially inclusive societies around the world has, in my opinion, been slow. One small example, the UN adopted the Universal Declaration of Human Rights in 1948, but the UN Convention on The Rights of Persons with Disabilities didn’t appear until 2006. Australia ratified the Convention in 2008 and while the US signed the convention last year it is still to be ratified by Congress.

In the real world, it is no longer the norm in many countries to segregate school children solely on the basis of a disability; rather everything is done to try to accommodate those with different needs within the general school environment. In Australia at least, schools for children who are deaf or blind are by and large a thing of the past. A few specialist schools do remain, and most of them primarily cater for children with multiple and sometimes profound disabilities.

Also, 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.

Changing attitudes can be a slow process, and the introduction of new technologies can sometimes become barriers or excuses that have to be overcome. If I might return to the classroom for a moment to help illustrate this point: When sighted impaired children were first integrated into the standard classroom environment it required a change in attitude on behalf of teachers as well as other children in the class. Some teachers found this particularly challenging, and if there was too much chalk and not enough talk the child who was unable to see the board was often left behind.

Today, we have many more visual teaching aids, such as PowerPoint, video, electronic whiteboards and of course the web. For some teachers these have become another excuse, or way of discounting, the importance of ensuring that those who are unable to see have equal access to education. Rather than changing teaching practices or providing accessible supplementary materials, it is easier for these teachers to fall back on the simplistic, utilitarian excuse of satisfying the needs of the greatest number of people. Thankfully, excuses like this should not, and are not, considered legally acceptable.

In the real world, one of the hallmarks of a civilised and inclusive society is a willingness to accept the differences in people and not discriminate against those with 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.

For the last 10 years we have had rules and guidelines promoting web content accessibility and contrary to what some people say, it is not difficult to make an attractive, modern site that complies with these guidelines. However as we all know, there are many inaccessible websites out there. What I believe we fundamentally need are changes in attitude, particularly on the part of site developers and their clients, as well as those in governments and industry with responsibility for regulating web content accessibility.

In a future post, I will be looking at the accessibility implications of the Australian Gov 2.0 draft report. From my reading, it seems to me that the authors of the report also ‘don’t get it’ when it comes to social inclusion. The report is available at http://gov2.net.au/blog/2009/12/07/draftreport/

Note: Social Inclusion and the role guidelines and rules play in promoting website accessibility are among the issues I will be discussing in my CSUN presentation.

WCAG 2.0 and Accessibility Supported

by
, , ,
8

Web accessibility is at the cross-roads. The WCAG of 1999 is not able to meet the needs of the web today, with its enhanced interactivity, greater community engagement and the proliferation of new technologies. WCAG 2.0 is supposed to address this problem by looking not at the technologies used to generate web content, but at how they are used. However, I am fearful that WCAG 2.0 and the concept of “accessibility supported” are not fully understood and this could put at risk the whole move to improve the accessibility of the web.

Many countries, including Australia are currently considering when and how to adopt WCAG 2.0 as the benchmark for accessibility. This issue was briefly canvassed in an earlier post, Adopting WCAG 2.0, and the comments it attracted.

Central to WCAG 2.0 is the notion of technological neutrality, since this will allow the guidelines to be applied to all current and future web technologies. In conjunction with this approach, the WCAG Working Group introduced the concept of “accessibility-supported” and the associated requirement that only accessibility supported ways of using technologies can be relied upon to satisfy the Success Criteria.

While I support the idea of WCAG 2.0 being technology neutral, I am concerned that there maybe a general misunderstanding in the web community about what is meant by “accessibility supported”. In particular, I am worried that regulators in Australia and other countries may be reluctant to fully embrace the notion of technological neutrality and continue to view web content accessibility from an exclusively HTML perspective. This appears to be basically the approach adopted by New Zealand.

It should be noted, when a technology is considered “accessibility supported” it doesn’t automatically mean all uses of that technology will be acceptable. PDF, JavaScript or Flash, for example, can all be used to make content that is either accessible or inaccessible as is also the case with HTML. For more information see the W3C Working Group note Understanding Accessibility Support.

If the authorities in different countries, who set the rules and regulations relating to the accessibility of web content, decide that only W3C formats like HTML and CSS can be considered accessible, then alternatives will have to be provided for all content that relies on other technologies. This is basically how we have operated for the ten years of WCAG 1.0 and I believe to continue with this approach risks jeopardising the overall accessibility of the web. A failure to accept new technologies will in my opinion:

  • Provide little incentive for website developers to improve the accessibility of web content that uses non-W3C technologies like JavaScript and PDF.
  • Reduce pressure on the producers of current and future non-W3C technologies to improve the accessibility of their technologies and associated authoring systems.
  • Reduce the incentive for the manufacturers of assistive technologies to improve the ability of their technologies to render non-W3C formats.
  • Undermine the overall community perception of the importance of web content accessibility as interactive non-W3C technologies are increasingly used on high traffic websites often without appropriate alternatives.
  • Result in an increasing number of sites being technically in breach of web accessibility regulations, and since the vast majority of these breaches are not likely to be prosecuted this will further undermine the credibility of accessibility-related rules and regulations.

But, what about all the inaccessible non-W3C content now on the web?

We all know that the web now contains a large amount of PDF and Flash material that is inaccessible. There is also poor JavaScript that prevents users who depend on assistive technologies from accessing the content and functionality of some sites. And, from my experience, nearly all of this inaccessible non-W3C content on Australian websites is not being corrected. A few site proprietors, who are committed to improving the accessibility of their sites, are progressively addressing the problem caused by old inaccessible content, but most just don’t think it is worth the time or money.

In addition to allowing a wide range of technologies to be considered “accessibility supported”, I believe the regulators in Australia (and elsewhere) should consider providing a moratorium or exemption for all existing non-W3C content, such as Flash or PDF, which does not comply with WCAG 1.0. The providers of this content should however be required to supply a description of what the content contains, but not a full equivalent alternative that is accessible.

I recognise that in effect this approach will give tacit approval to a potentially large amount of inaccessible content on Australian websites. However, I think it is unlikely an alternative, more punitive, approach will result in any significant improvements in the accessibility of the non-W3C content that is currently available.

With regard to JavaScript, in my opinion no alternative should be required for JavaScript that is accessible to versions of commonly used assistive technologies, which have been released in the last three years. An alternative that does not rely on JavaScript support however, should be provided for all Script that is inaccessible.

In my view, we need to look forward, not back. Rather than putting a lot of effort into correcting the accessibility failures of the last ten years, we should put in place a process that embraces the diversity of technologies, which are now available, so long as they are used in a way that is accessible. The regulators and the web community as a whole should then take a more active role in ensuring web content meet the requirements of WCAG 2.0.

I am keen to read the opinion of others on this issue as I suspect the approach outlined above will not be acceptable to some people.

Adopting WCAG 2

by
, , ,

It is six months since the release of WCAG 2.0 and I thought it might be interesting to see how extensively it has been adopted as a bench mark for determining web content accessibility. Over this time, I have felt that the rate of adoption has been relatively slow and the number of countries and other regulatory authorities now using WCAG 2 is lower than I expected. Of course, this could just be the result of me having overly optimistic expectations.

At the outset, I would like to make it clear that I am a supporter of WCAG 2. Of course, like many other people concerned with accessibility, I have a few quibbles about some of the details, but overall I think the new guidelines and the move to technological neutrality are good.

In Australia, regulations relating to website accessibility are to a large extent determined by two bodies; the Australian Human Rights Commission (AHRC) and the Australian Government Information Management Office (AGIMO). At this time, it seems to me that AHRC are keen to move to WCAG 2, perhaps with a few conditions, but there is a certain inaction (or reluctance) on the part of AGIMO, which is primarily responsible for setting web standards for all Commonwealth (Federal) government agencies. As a result WCAG 1 is still the referenced benchmark for website accessibility. (World Wide Web Access: Disability Discrimination Act Advisory Notes)

In an attempt to find out what is happening in other countries I sent a request for information to the WAI Interest Group mail list. Many thanks to Harry, Denis, Christophe (P and S), Mike, Hiro, Cale, Bruce and Anthony for the information they provided.

The following is a brief summary of what I have found so far. Please note it may not be completely accurate and I take full responsibility for any mistakes it contains.

  • The first country to adopt WCAG 2 as a general requirement appears to be New Zealand, where Government Web Standard 2.0 that was released in March 2009 incorporated WCAG 2 (Level AA) as the standard for accessibility. When it comes to the issue of what technologies might be consider “accessibility supported” and “relied upon”, New Zealand has taken what could be described as a minimalist approach that is similar to WCAG 1. Content must be accessible without JavaScript and/or CSS support and, with a few specified exceptions, a HTML alternative has to be provided for all other content formats including Flash, PDF and Word.
  • In Canada, at the Federal Government level, the “Common Look and Feel Guidelines” incorporate an accessibility requirement which is based on WCAG 1 (Level AA). At this stage there appears to be no indication if or when they might move to WCAG 2. At the Provincial level, some provinces are reported to be actively moving to WCAG 2 and it is expected to be adopted at Level AA by at least a few by the end of the year.
  • Within the European Union Commission there is a reported consensus that WCAG 2.0 provides an opportunity for a common approach to web accessibility across Europe, which should not be missed. However, there are differing views about which sites accessibility regulations should apply to and the processes for determining conformance. (Expert meeting on web accessibility in Europe and the implementation of WCAG 2.0)
  • The Netherlands is currently in the process of updating its Web Quality guidelines to reflect WCAG 2.
  • In the UK the official government policy remains WCAG 1 (AA). However, it appears that within Government departments there is a growing acceptance that websites under development should conform to WCAG 2 (AA), but I am not aware of the precise details.
  • In Belgium web accessibility requirements are contained in a document called “Any Surfer” which appears to be primarily based on WCAG 1. However, I understand they are trying to follow the spirit of WCAG 2 with particular reference to the specific assistive technologies used in Belgium and within the constraints of available tools.
  • Japan has just completed the working draft of a standard on Web content accessibility that is harmonized with WCAG 2.0.

I understand many other countries, including France, Germany, Spain and India for example, have regulations relating to web accessibility that are based on the Web Content Accessibility Guidelines. I don’t know what moves, if any, these countries have made towards adopting WCAG 2 as the benchmark for determining website accessibility.

Please let me know if I have made some errors in this article or if you have any information regarding the adoption of WCAG 2 that you wish to share. I will update this article as I obtain new information.

UPDATE

Many thanks for the comments about the situation in other countries. Ginger has sent me an email asking me to include the following:

  • In Germany we do not use the WCAG but they are incorporated in the BITV regulation, which need to be followed for all public websites. Currently, we are using the BITV v1 (incorporating WCAG 1.0). A new version has been written to adopt the new issues addressed by WCAG 2.0. But there is a problem in putting them into affect: Since Germany is a member of the European Union certain laws and regulations need to be passed by the Commission. When they found this out they decided to postpone this decision until we have elected a new government in September of this year. Federal departments are busy right now with the election and since all parties can ask the Federal departments for comments about certain topics in the election period, they are not able to handle the extra work of introducing BITV v2. In October they might think about introducing it, but if the Government changes they might want more discussions about BITV v2. We do not expect the WCAG 2.0 to be effective here before mid 2010.

See the comments below for information about the adoption of WCAG 2 in other countries.

I would be very interested to know how different countries and organisations are dealing with the issue of determining which technologies developers can consider to be ‘accessibility supported’. For example, is it possible to use JavaScript (assuming it is used in a way that is accessible) without having to also provide a non-JavaScript alternative?

Refreshable Braille and the Web

by
, ,

Many people have not had the opportunity to see someone use a refreshable Braille device to access the web. I recently videoed Bruce Maguire describing how he uses the internet with a refreshable Braille display. He also demonstrates finding a book on the Amazon site. Transcript of the video is at the end of this document.

Bruce has been using Braille since he was 5 years old. He also has impaired hearing and his preferred method of accessing the web is to use a screen reader in conjunction with a refreshable Braille display. The refreshable Braille device contains a strip of rubberised material under which, is a row of pins that rise and fall in response to the content of the web page. These pins form the Braille characters, and as the user moves around the content of the page, they constantly refresh the line of Braille characters to read what comes next.


Video: Bruce talks about refreshable Braille

Video Transcript

TITLE CARD: “Bruce talks about refreshable Braille”

Bruce: I’m Bruce Maguire. I’ve been using Braille all my life as a blind person and when I use the internet and computers generally I prefer to work in Braille. Mainly because it gives me a greater sense of engagement with the text and the content, I can reflect on it, I can re-read it as much as I want and I can put my own interpretation on what I am reading rather than having a synthetic voice or even a human voice do it for me. I also have a hearing impairment so it is easier for me to use Braille rather than synthetic speech. In this little demonstration today I will turn the synthetic speech of my screen reader on so that you can hear what I am doing as I navigate around the page.

SHOT OF REFRESHABLE BRAILLE DEVICE

Bruce: The refreshable Braille display, at the heart of it is essentially a lot of pins that move up and down to form the Braille characters in response to the impulses the computer sends them based on what’s on the computer screen.

BRUCE SITTING AT DESK

Bruce: So under my fingers I can feel Australian Human Rights Commission, and if I get the …

PUSHES KEYBOARD KEY

Screen Reader: Heading level 1, link graphic Australian Human Rights Commission, heading level 1.

Bruce: And the speech says effectively the same thing. The speech gives you a little more information in terms of; it says that it’s a heading. Umn, I can have my refreshable Braille display give me the same information as well. Now as I use the arrow key I can move down the page to see what’s there …

FINGERS ON KEYBOARD

Screen Reader: Blank, same page link skip to content, alt plus 2. Blank, search alt plus 5.

CU BRUCE

Bruce: I can move quickly from one element of the page to another, for example from one heading to another …

Screen Reader: After 30 years PML finally in “colon” a great first step, heading level 3 link. About the Australian Human Rights Commission, heading level 2.

CU KEYBOARD. KEY PRESS

Screen Reader: General information, heading level 2,

Bruce: And, in each case, I’m feeling under my fingers the same text as what is being announced by the speech synthesizer, so I can turn the synthesizer off, which is what I normally do, and just use the Braille to navigate around.

CAMERA TILT UP TO BRUCE FACE

Bruce: Braille in some ways; in some areas it is faster and more efficient to use than synthetic speech for navigating web pages, and in some cases it’s a little slower particularly if you want to read long documents, because the Braille display gives you 32 characters at a time. So that, when you’ve read the first chunk of 32 characters you have to press one of the keys on the Braille display to read the next chunk of 32 characters.

CU THUMB PUSHES BRAILLE REFRESH BUTTON –
CU FINGER RUNNING BACK AND FORTH ACROSS DISPLAY PINS

Bruce: So, I am on a line here which says;

Screen Reader: Working towards an Australian society where human rights are for everyone, everywhere, every day.

Bruce: Now, so that’s the text of this particular line on the page. Under my fingers on the Braille Display I can read, “Working towards an Australian …” And I have to then press a key to go to the next chunk which is “society where human rights are …”

CU THUMB PUSHES BRAILLE REFRESH BUTTON

Bruce: “for everyone, everywhere, everyday.”

BRUCE AT DESK

Bruce: I use the internet for many purposes including online grocery shopping, browsing book and music stores. As a blind person one of the things that I found most frustrating over the years is that I can’t just walk into a shop and browse the aisles and as I am an avid book collector that’s been a particularly difficult thing to adjust to, but when the internet developed and we have online stores such as Amazon and Barnes and Noble and in Australia Fishpond, being able to browse and buy online has been a great thing. I also use the internet for work related purposes, accessing government information, accessing disability related websites.

TITLE CARD: “Shopping Online”

Bruce (voice over): I’ve turned the speech off now, what I might do is demonstrate how I would buy a book. So the Amazon site has just come up and I know that …

HANDS ON KEYS

Bruce: because under my fingers on the Braille display I can read, “Amazon, online shopping for electronics, apparel, computers, books, DVDs and more.” And having used this site before I know I can just press a key on the keyboard to take me to the first field. And under my fingers I read all departments.

PRESSES ANOTHER KEY, THEN MORE KEYS

Bruce: So I want to arrow down to books. And I want to look for books by an author called Anita Roddick who founded the Body Shop. TYPES And, has written some very interesting books about the importance of advocacy. So I type Anita Roddick on the keyboard and under my fingers I can verify that I have typed what I think I’ve typed by feeling Anita Roddick.

CU BRUCE

Bruce: Now we’ve got the search results, and the first book I notice here is “Business as Unusual, My Entrepreneurial Journey, Profits with Principles” by Anita Roddick.

CU HANDS

Bruce: Paperback May 30 2005. I can buy new for $12.65, or that’s retail price, and the Amazon price is $10.36, or there’s 51 used from $1.59 and I can get it if I am in the US by Tuesday May 12 if you order in the next 22 hours and choose 1 Click Shipping.

CU BRUCE

Bruce: So that’s the kind of thing that I can do with the Braille display quite efficiently and as I mentioned, being able to do this sort of thing is still something that I find a wonderful thing because being an avid book collector I can now fuel that addiction to my heart’s content.

FADE TO BLACK

WCAG 2.0 Released: At last

by
, ,
Reply

After a long and sometimes tortuous process, the W3C has finally released Version 2 of the Web Content Accessibility Guidelines on December 11 2008.

PRESS RELEASE

“Today W3C announces a new standard that will help Web designers and developers create sites that better meet the needs of users with disabilities and older users. Drawing on extensive experience and community feedback, the Web Content Accessibility Guidelines (WCAG) 2.0 improve upon W3C’s groundbreaking initial standard for accessible Web content.”

More at http://www.w3.org/2008/12/wcag20-pressrelease.html

WCAG 2 starts with 4 basic principles of Web accessibility – often referred to as the POUR principles:

  1. Perceivable – Information and user interface components must be presentable to users in ways they can perceive.This means it can’t be invisible to all 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 that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. It also means that the content should remain accessible as technologies and user agents evolve in the future.

Each principle contains a number of Guidelines and for each Guideline there are Success Criteria, which are basically testable statements. Advice about how to satisfy the Success Criteria is provided in a Techniques document. For each Success Criteria the document outlines “Sufficient Techniques” for meeting the Criteria and “Advisory Techniques”, which go beyond what is required, but provide suggestions about how to better address the guidelines. Known common failures to comply with a Success Criteria are also documented.

Unlike WCAG 1.0, WCAG 2.0 has been developed so that it can apply to current web technologies and to future web technologies irrespective of whether they are W3C technologies or have been developed outside the W3C, for example JavaScript, Flash, PDF etc.

As a result, WCAG 2.0 introduces the concept of “accessibility-supported” and the associated requirement that ” only accessibility supported ways of using technologies can be relied upon to satisfy the Success Criteria”.

The W3C does not specify how many, or which assistive technologies, such as Screen readers, must support a Web content technology like Flash in order for it to be considered “accessibility supported“

Also, there is no expectation for all uses of a web content technology to be accessible; but only those uses that are accessible can be relied upon when considering whether or not a site or application is accessible.

The W3C expect that lists will emerge over time of which technologies, and under which conditions, can be considered to be “accessibility supported”. And already there are a couple of W3C reports on accessibility support for ways of using web technologies, including this one about PDF.

It seems to me, the W3C is suggesting that when considering whether or not the use of a particular web content technology is accessibility supported you should:

  1. Look at the environment where the proposed web technology will be used. And in particular, the assistive technologies that are available to the intended users.
  2. Make sure the web content technology you are planning to use has user agents like readers and media-players that work with assistive technologies and don’t discriminate against people with disabilities in terms of availability or price.
  3. Make sure the web content technology you are planning to use is supported by commonly used assistive technologies – not just the latest version, or some new fangled thing.
  4. Make sure you use the web content technology in a way that supports accessibility – that is make the material well.

I feel WCAG 1.0 was well past its use-by-date and the new Guidelines are a significant improvement. However, I am a little worried that the notion of “accessibility supported”, and who decides whether or not some technology is sufficiently supported, will open a whole new can of worms for regulatory authorities around the world as they try to set web accessibility standards that they can enforce.

WCAG 2.0 Recommendation is at http://www.w3.org/TR/2008/REC-WCAG20-20081211/

The Techniques for WCAG 2.0 document is at http://www.w3.org/TR/WCAG20-TECHS/

Use of Web 2.0 Tools

by
, , ,
Reply

Roger Hudson

26 December 2008

SUMMARY

At the Oz-IA 2008 Conference in Sydney, I gave a talk about the different ways information on the web can be identified and found. The talk included the findings of a recent survey into the use of Web 2.0 tools, which suggest that a far smaller percentage of the general community use web 2.0 tools than we sometimes expect, and those who do use them, do so much less often. The presentation also considered how Pace-Layering theory might be applied to the process of developing websites. The presentation slides are now available on SlideShare.

1. INTRODUCTION

During August and September 2008, I did a quick survey to gain some insights into how people use some of the newer features of the web such as blogs, tags and social networking sites. I was also interested in comparing the extent to which these tools are used by people who work making sites with those who just use web. The survey was part of research for a paper I was presenting at Oz-IA 08.

The survey considered these issues:

  • How many people provide comments on the web pages of others?
  • How many people have their own blogs and comment on the blogs of others?
  • How often is content tagged and how often do people use tags and tag clouds when retrieving information from sites?
  • How much do people use video and photo sharing sites like Flickr and Youtube?
  • How much do they use social networking sites like Facebook and Myspace?
  • And finally, how much do they use RSS?

2. PARTICIPANTS

I surveyed 90 people, with two broad categories of participants:

  • People employed in the preparation of websites (30 people)
  • People who just use the web either socially or for work (60 people)

The first group (web professionals) contained two sub-groups: web evangelists, 10 people who were surveyed at a Web Standards Group meeting; and, web workers, 20 people whose everyday work involves the preparation of websites and who were surveyed in the workplace.

For the general web users, I surveyed 10 people from 6 different categories of users. 50 participants came from 5 targeted groups; volunteers for a not-for-profit organisation, museum scientists and project officers, media workers, school teachers and tertiary students. 10 participants were untargeted members of the general community.

All the participants were randomly selected and I had no knowledge of how any of the participants used the web prior to the survey.

3. QUESTIONS

The survey contained a total of 21 questions that relate to the use of: blogs, content tagging and tag clouds, video and photo sharing sites, social networking sites and RSS.

The aim of the questions was to determine how often each participant used a particular web tool or feature, and how they used it. For example, one question asked participants to indicate if they had blog. And for those who answered yes, there was a follow-up question asking how often they made a new posting. The next question asked if the participant had ever commented on the blog of someone else. Once again, there was a follow-up question asking those who had made comments to indicate how often they did so.

Basically the survey considered passive use of the tools such as looking at the photos or video of someone else. And active use like putting photos or videos on a sharing site, having your own blog or Myspace page or providing tags for some web content.

After completing all the surveys, I collated the responses to each question by participants in each survey category and averaged the results. This gave an averaged usage score by survey category for each question, expressed as a percentage.

4. RESULTS

I haven’t got time to go through all of the results, so I will give a quick overview and confine myself to commenting on those which I think are most interesting.

The averaged results for the 11 main questions in the survey for both categories of users provide a useful overview of how much the tools are used.

Web professionals: The tools were used on average by 62% of participants

  • Web evangelists – 84%
  • Web workers – 51%

Web Users: The tools were used on average by 38% of participants

  • Not-for-profit volunteers – 41%
  • Museum staff – 35%
  • Media workers – 43%
  • Teachers – 25%
  • Tertiary students – 63%
  • General community – 23%

When it comes to web professionals, as might be expected, a greater percentage of the evangelists used all of the tools, and they used them more often, than those who were surveyed at their place of web work.

As can be seen however, there was a much larger variation in the responses from the different categories of web users, with the tools used on average by 63% of the students, while at the other end of the scale, the general community participants had an average usage of 23% and for teachers it was only slightly greater at 25%.


NB: The high level of average usage by students was boosted by the fact that they had all visited a photo or video sharing site and all had social networking pages and had visited the social networking pages of others.

Apart from the great difference between scores of 84% and 23%, I think the overall results provide two other points of particular interest:

  1. The significant difference between the evangelist and web workers, particularly when it came to tagging
  2. The relatively low usage scores for teachers, media workers and to a lesser extent Australian Museum staff, since I would have thought that nature of their work would have exposed them more to these tools and their potential benefits.

5. PASSIVE AND ACTIVE USE

When we look in more detail at how these tools are used, there is quite a difference between what I call Passive use, which is visiting or looking at the contributions of others, and Active use such as making comments, putting up material or providing tags.

As might be expected, in both areas of use, the web evangelists surveyed at a WSG meeting reported much high usage. With Passive use for example, all of the evangelists said they had visited a social networking page or viewed a photo or blog of someone else, compared to about 80% for the other participants. There was a greater difference in the use of tags (or tag clouds) to locate information with 90% of evangelists saying they used them compared to just 27% of general web users (and I suspect this score is a little inflated).

When it came to Active use, the differences were more striking:

Active Use (% of participants)
Web Evangelists Web workers Web Users

(general community)
Made comment on web page or blog 85 55 34
Posted photo/video 70 45 22
Commented on photo/video (eg Flickr) 60 50 32
Own social network page (eg Myspace) 100 60 55
Tagged web content 90 20 18

As we can see here, the evangelists significantly out score the other two categories when it came to actually putting content, comments or tags onto the web. While this fact alone doesn’t surprise me, there are a few interesting things to consider:

  1. The difference between the number of web evangelists and web workers who use these features to make comments, upload content etc. I would imagine all the web workers are aware of all these facilities so I can only assume that their lower level of participation is due to a conscious decision and not because of a lack of knowledge.
  2. The percentage of people who made comments on web pages or blogs; with 85% of evangelists saying they had done so, compared to one third of the non-web professionals surveyed.
  3. The huge difference in the reported tagging of web content; ranging from 90% for the evangelists down to 20 and 18 percent for web workers and people who just use the web. (I suspect the 90% figure is inflated by people including the provision of tags for their own photos and video material which was not the intention of this question).

6. AGE DIFFERENCE

I think it is worth making a quick mention of difference levels of use by participants of different ages. Although the survey had six age categories, for the purposes of this article I have collated the results into two age brackets; those 30 and under (32 participants) and those 31 and over (58 participants).

Use by age difference (% of participants)
30 yrs or less
(n=32)		 31 yrs or more
(n=58)
Made comment on web page or blog 56 40
Posted photo/video 44 28
Commented on photo/video (eg Flickr) 62 29
Own social network page (eg Myspace) 97 40
Tagged web content 44 17
Subscribe to RSS 37 34

As might be expected, the younger group are more likely to have their own Facebook, Myspace or beebo type page or to be actively involved in posting photos or videos and commenting on those of others. However, these differences are not much as I was expecting.

I think the relative lack of difference when it comes to commenting on web pages or blogs or subscribing to RSS is interesting. In the case of commenting, one possible reason might be that it more closely resembles the feedback mechanisms of traditional media such as letters to the editor and even talk back radio, which the older participants are likely to be very familiar with. When it comes to RSS, established media outlets like the ABC and the sites of daily newspapers (e.g. Sydney Morning Herald) have clearly demonstrated how useful these can be to the average web user over the last few years.

7. CONCLUSION

I would like to start by making it clear that this survey does not set out to state that a certain tool is likely to be used by x% or the population with a y% margin of error. Rather, my aim is to provide some insights into the level of usage of these tools by different groups of people.

These are my overall conclusions which I hope you find interesting and useful:

  1. Most notably, the striking disparity between how much these tools are used by web evangelists when compared to people who see the web as just another everyday thing to be used in an everyday way.
  2. This difference in usage also extends to web workers who are not evangelists. They also just see the web as something that they work with and not some all encompassing passion. To quite a large extent the behaviour of the standard web workers more closely matches that of everyday web users rather than the evangelists.
  3. With reference to the “tagging” of web content, if we exclude the web evangelists only about 20% of participants said they had tagged content.
  4. While many more young people are likely to have a Myspace page, age alone is not a particularly strong indicator of the likelihood of someone using these new tools. There were participants under 20 with no interest in commenting, tagging or RSS; just as there were people over 60 who did all these things regularly.
  5. Web evangelists are not a good guide to web behaviour or how likely the general community are to adopt new ideas.

In summary, when it comes to use of the web 2.0 style features that I considered, a smaller percentage of the general community than we sometimes expect use them, and those who do use them, do so much less often.

Accessible forms using WCAG 2.0

by
, ,

“Accessible Forms using WCAG 2.0” is the first of a series of documents to help web professionals use the Web Content Accessibility Guidelines Version 2.0 to develop accessible websites.

This document aims to provide web developers and others with practical advice about the preparation of accessible HTML forms. It compares the WCAG 1.0 accessibility requirements relating to forms with those contained in WCAG 2.0.

I wish to thank Chris Bentley, Andrew Downie and Russ Weakley for their considerable knowledge and assistance in preparing this document.

NB: This document is a work-in-progress. Please send feedback and any suggestions about errors and omissions to rhudson@usability.com.au

Introduction

Web Content Accessibility Guidelines Version 1.0 (WCAG 1.0) is primarily concerned with advocating the use of W3C Technologies such as HTML and CSS to prepare accessible websites. Version 2.0 of the Guidelines is technology neutral. That is, WCAG 2.0 does not explicitly relate to the use of HTML but is concerned with improving the accessibility of sites regardless of the technologies used.

As part of this new approach, WCAG 2.0 incorporates the notion of “accessibility supported technologies” defined as:

“An accessibility supported technology is a technology (HTML, CSS, etc.) that will work with assistive technologies (AT) and the accessibility features of browsers and other user agents. Only technologies (including features of the technologies), that are “accessibility supported” can be used to conform to WCAG 2.0 Success Criteria.”

Although there is no list of recognised “accessibility supported technologies”, it is expected that all W3C technologies and common non-W3C technologies (e.g. JavaScript and Flash) when used appropriately will be considered accessibility supported.

WCAG 2.0 is built around 4 basic principles. Within these principles, there are 12 Guidelines which contain a total of 61 “testable” Success Criteria. Each Success Criteria is assigned one of three defined levels of conformance: A (lowest), AA, AAA (highest).

For each Success Criteria, the WCAG Working Group has provided “Sufficient Techniques” which they have deemed to be sufficient for satisfying the Success Criterion.

The Web Accessibility Initiative (WAI) has released the following primary WCAG 2.0 documents:

The various forms presented in this document have been tested will the following screen readers JAWS 7.1, JAWS 9 and Window-Eyes 6.1.

Forms: Accessibility and Assistive Technologies

Forms can present problems for web users with vision and/or mobility impairment and for people with cognitive or learning disabilities. Someone with impaired vision who relies on an assistive technology such as a screen reader with audio and/or Braille output can easily get lost in a badly made form. For these devices to work effectively, the technology needs to be able to associate a form label (request or prompt) with the correct form control, such as a text field or checkbox.

Many people with vision and mobility disabilities interact with the web (and forms) using primarily the keyboard rather than a mouse. As a result their interactions tend to be sequential with the sequence order largely controlled by the way the page has been designed.

Screen readers allow users to interact with a web page in a variety of ways. As a default, screen readers will sequentially read the content of the page; with JAWS this is called “Virtual PC Cursor” mode and with Window Eyes it is called “Browse Mode”. For convenience, this document will refer to this default mode of access as “Read” mode. Using Read mode, users can quickly locate a form on a page and scan its content.

When the user needs to enter text into the form, they must use the keyboard to turn the Virtual Cursor off and in JAWS parlance switch to “Form” (input) mode. With Window Eyes the user must switch to “Browse Off ” mode. This will be called “Form” mode in this document.

In Form mode, the user is basically restricted to moving between elements on the page that can accept focus (eg form inputs and links) and this means that if they need to read surrounding material such as paragraphs or headings they have to go out of Form mode.

Form Input Labels

Two WCAG 1.0 Checkpoints relate directly to the use of labels for forms:

“Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels ensure that the label is properly positioned.” [Priority 2]

WCAG 1.0 Checkpoint 10.2

“Associate labels explicitly with their controls. For example, in HTML use LABEL and its “for” attribute.” [Priority 2]

WCAG 1.0 Checkpoint 12.4

Combined these two checkpoints, when read in conjunction with the HTML 4.01 specification, appear to require all form inputs to have a label that is correctly positioned and explicitly associated with the control (input).

None of the WCAG 2.0 Success Criteria directly mention HTML or forms. However, the following two Success Criteria are concerned in part with identifying form controls.

“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

“Labels or Instructions: Labels or instructions are provided when content requires user input.” (Level A)

WCAG 2.0 Success Criteria 3.3.2

Success Criteria 1.3.1 and 3.3.2 both contain the following Sufficient Techniques (HTML):

H44: Using label elements to associate text labels with form controls (HTML)

H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)

Explicit association

Sufficient Technique H44 is very similar to WCAG 1.0 Checkpoint 12.4 in that it requires form labels to be explicitly associated with their controls.

Explicit association means that the HTML element “label” with the “for” attribute, and the input attribute “id” should be used to associate a text or graphic label with a specific form control. The attributes can be used with nearly all input elements, including text boxes, checkboxes and radio buttons, textarea and select. However, the “id” attribute for each element (radio button, text etc) in a document must be unique.

Simple form showing appropriate position of labels:

Screenshot of form 1

Form 1: Correct position and explicit association of labels

The following excerpt of code for the form above uses “label for” and “id” to explicitly associate the text input and radio buttons with their labels.

HTML

<form action="#" method="post"> <div> <label for="nm">Name: </label> <input id="nm" type="text" name="name" value=""> </div> <div> <input id="yes" name="request" value="yes" type="radio"> <label for="yes">Yes</label> &nbsp; <input id="no" name="request" value="no" type="radio"> <label for="no">No</label> </div> </form>

In Read mode, the JAWS screen reader will present the simple form above like this:

Name colon, name colon edit. Radio button not checked, yes. Radio button not checked, no.

When you switch to Form mode the form is presented like this:

Name colon edit, type-in-text. Yes radio button not checked. One of two, to change the selection press up or down arrow keys.

Another benefit of explicitly associating a label with its control (input) is an increase in size of the area that can be clicked to access the input. This is particularly helpful for people with diminished vision or fine motor skill difficulties, but who are still able to use a mouse. With a text input (like the name example above) clicking anywhere on the label or textbox will put the cursor at the beginning of the text input area. Similarly, a radio button or checkbox can be checked by clicking either the label or button (or box).

NOTE: The label element is not used for the following because labels for these elements are provided via the value attribute (for Submit and Reset buttons), the alt attribute (for image buttons), or element content itself (button).

  • Submit and Reset buttons (input type=”submit” or input type=”reset”)
  • Image buttons (input type=”image”)
  • Hidden input fields (input type=”hidden”)
  • Script buttons (button elements or <input type=”button”>)

Source: WCAG 2.0 Technique H44:

Title attribute

When it comes to identifying form controls, one of the most significant advances with WCAG 2.0 is Sufficient Technique H65 that allows the form control title attribute to be used for this purpose, “when the visual design cannot accommodate the label or where it might be confusing to display a label”.

For design reasons, the site-search form input field at the top of pages on some sites are presented without a label. In order to fully comply with WCAG 1.0, some developers have provided a non-visible label for these search inputs by using the CSS “off left” technique to remove the label from the display area while still allowing it to be accessed by screen readers. With WCAG 2.0, the use of the form control title attribute is deemed a Sufficient Technique.

Screenshot of form 2

Form 2: Site-search form input without label

When no label is provided for a form control, as in the example above, some screen readers will automatically associate the immediately preceding piece of text with the control. With the example above, this could lead some screen reader users to believing that the input relates to searching for information just about employment issues.

However, when no label is present and the title attribute for the form control (text input field) is used, recent versions of both JAWS and Window-Eyes will present the title attribute when the form control receives focus.

HTML

<div id="global"> <ul> <li><a href="#">About us</a></li> <li><a href="#">Services</a></li> <li><a href="#">Employment</a></li> </ul> <form method=get id="searchform" action="/search.php"> <div> <input type="text" title="site search" name="query" id="q" value=""> <input type="submit" value="search"> </div> </form> </div>

Sometimes, forms need to provide information that relates to a following question. When this information is presented as a heading, or sentence/paragraph as in Form 3 below, it will not be presented by the screen reader when it is in Form mode. One way of ensuring this information is presented in Form mode is to use the information as the “legend” within a “fieldset”. (See later section, Grouping Form Elements.)

Since use of the title attribute to identify a form control is a Sufficient Technique in WCAG 2.0 this provides another potential way of addressing this issue.

Screenshot of form 3

Form 3: Form with radio buttons that use title attributes

HTML

<form action="#" method="post"> <div> <label for="name">Name: </label> <input id="name" type="text" name="name" value=""> </div> <div> <label for="email">Email: </label> <input id="email" type="text" name="email" value=""> </div> <p> Choose a subscription option from below: </p> <div> <input id="Weekly" title="weekly subscription" name="subscribe" value="Weekly" type="radio"> <label>Weekly</label> <input id="Monthly" title="monthly subscription" name="subscribe" value="Monthly" type="radio"> <label>Monthly</label> <input id="Quarterly" title="quarterly subscription" name="subscribe" value="Quarterly" type="radio"> <label>Quarterly</label> </div> </form>

When the form above is presented by JAWS in Read mode, the instruction, “Choose a subscription option from below” followed by the radio buttons is presented as follows:

“Choose a subscription option from below colon.”

“Radio button not checked weekly subscription. Weekly”

“Radio button not checked monthly subscription. Monthly”

“Radio button not checked quarterly subscription. Quarterly”

In Form mode the instruction paragraph is not read. However, the aim of the radio buttons is clearly communicated by screen reader presenting the title attribute for each of the radio buttons as follows:

“Weekly subscription radio button not checked; One of three. To change the selection press up or down arrow. [Press down arrow]”

“Monthly subscription radio button checked; two of three. To change the selection press up or down arrow. [Press down arrow]”

“Quarterly subscription radio button checked; three of three. To change the selection press up or down arrow”

Window Eyes also effectively presents the title attribute in both Read and Form modes, although Window Eyes does generally tend to use fewer words.

It worth mentioning that with both JAWS and Window Eyes, it is not necessary to switch to Form mode (that is turn off the Virtual cursor or Browser mode) in order to make a radio button or checkbox selection.

VIDEO 1: Screen reader reporting of explicit association and title attribute

Form controls in data tables

Some data tables contain form inputs that can be used to enter information. For example a form for ordering quantities of different products or a form for depositing money in different accounts as shown in the simplified example below.

Screenshot of form 4

Form 4: Data table containing form text input fields

The inclusion of a label for each of the form inputs, which can be used to enter information in the table above, is both unnecessary and redundant. Under WCAG 2.0, the use of the title attribute, as shown in the code excerpt below, would be a Sufficient Technique and would probably be the most feasible approach in situations like this.

HTML

<form action="#" method="post"> <table summary="form for allocating deposits to different accounts"> <caption><strong>Deposit form</strong></caption> <thead> <tr> <th>Account name</th> <th>Account balance</th> <th>Deposit amount</th> </tr> </thead> <tbody> <tr> <th>Personal savings</th> <td align="center">$1,200.00</td> <td align="center"><input type="text" title="deposit amount for personal savings" value=""></td> </tr> <tr> <th>Investment account</th> <td align="center">$2,200.00</td> <td align="center"><input type="text" title="deposit amount for investment account" value=""></td> </tr> <tr> <th>Holidays</th> <td align="center">$3,200.00</td> <td align="center"><input type="text" title="deposit amount for holidays" value=""></td> </tr> </tbody> </table> </form>

When the “Deposit form” above is accessed by JAWS in Read mode, the screen reader identifies a cell containing the form input and presents the control title attribute as follows:

Deposit amount for personal savings, edit.

If the user wishes to make an entry into a particular form field, they will then need to switch to Form mode. The JAWS screen reader will then present the title attribute of each input as the user tabs through the form:

Deposit amount for personal savings edit, type-in-text. [tab]

Deposit amount for investment account edit, type-in-text. [tab]

Deposit amount for holidays edit, type-in-text.

When the “Deposit form” is accessed with Window Eyes a very similar thing occurs.

Video 2: Showing how screen readers report the deposit (data table) form above

Grouping Form Elements

A form where different elements are well organised with similar ones grouped together is easier for everyone to use. Grouping form elements together can be particularly helpful for people who depend on screen readers and for those with cognitive or learning disabilities.

Under WCAG 1.0, Checkpoint 12.3 advocates the use of the HTML elements “fieldset” and “legend” for this purpose.

“Divide large blocks of information into more manageable groups where natural and appropriate. For example, in HTML, use OPTGROUP to group OPTION elements inside a SELECT; group form controls with FIELDSET and LEGEND; use nested lists where appropriate; use headings to structure documents, etc.” [Priority 2]

WCAG 1.0 Checkpoint 12.3

In WCAG 2.0, Success Criteria 1.3.1 contains the following three Sufficient Techniques which fundamentally address the same issue:

H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)

H82: Grouping form controls with FIELDSET and LEGEND (HTML)

H85: Using OPTGROUP to group OPTION elements inside a SELECT (HTML)

“Fieldset” and “legend”

The HTML elements “fieldset” and “legend” allow forms with different areas of interest to be organised in a logical way. As a default, the “fieldset” element will create a box around the selected section and the “legend” will be in bold. In this way, form elements can be grouped together into identified categories. For example:

Screenshot of form 5

Form 5: Fieldset and legend

HTML

<fieldset> <legend> Personal Details</legend> <div> <label for="name">Name:</label> <input id="name" type="text" name="name" size="30"> </div> <div> <label for="idnum">ID Number:</label> <input id="idnum" type="text" name="id number" size="20"> </div> </fieldset>

Different browsers may display the default “fieldset” border in different way. Cascading Style Sheets can be used to remove the border or change its appearance.

Most screen readers will identify the different items within a “fieldset”. In ‘Form’ mode JAWS reports the value of the “legend” before the label for each control contained within the “fieldset”. The Personal Details form above is presented by JAWS in ‘Form’ mode like this:

Personal details, name colon edit, type-in-text

Personal details, ID number colon edit, type-in-text

Window Eyes identifies when a “fieldset” starts and ends and reports the “legend” at the beginning of the “fieldset”.

Nested “fieldset”

A “fieldset” can be nested inside another “fieldset”. For example:

Screenshot of form 6

Form 6: Nested Fieldsets

Care should be taken when nesting “fieldsets” to avoid making a form too complicated and to ensure the aim of the nesting is correctly presented by screen readers. For example, when an extra form control is presented after a nested “fieldset” as shown above, some screen readers will associate the preceding “legend” with the extra form control rather than the “legend” of the parent “fieldset”.

JAWS 7.1 in Form mode for example, reports the form with a nested fieldset shown above like this:

Participant, name colon edit, type-in-text [tab]

Areas of interest, writing checkbox not checked. To check press spacebar [tab]

Areas of interest, drawing checkbox not checked. To check press spacebar [tab]

Areas of interest, painting checkbox not checked. To check press spacebar [tab]

Areas of interest, pottery checkbox not checked. To check press spacebar [tab]

Areas of interest, companion colon edit, type-in-text

NOTE: The form label “Companion” is presented with the legend “Areas of interest”.

Video 3: Screen reader reporting of fieldset and legend

JavaScript

In general, WCAG 1.0 did not consider JavaScript universally accessible and required web pages to work without JavaScript support.

“Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.”[Priority 1]

WCAG 1.0 Checkpoint 6.3

When JavaScript was used, it had to be directly compatible with assistive technologies and not use device-dependent event handlers.

“Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.”[Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2]

WCAG 1.0 Checkpoint 8.1

“For scripts, specify logical event handlers rather than device-dependent event handlers.” [Priority 2]

WCAG 1.0 Checkpoint 9.3

A significant number of online forms however use JavaScript. Since most assistive technologies now support JavaScript when it is used appropriately, and most users of these technologies access the web with browsers and devices that are JavaScript enabled, the use of JavaScript per-se is no longer likely to cause significant accessibility problems.

Since WCAG 2.0 is designed to be technology neutral none of the Success Criteria relate specifically to the use of JavaScript. However, there are 5 Conformance Requirements that must be met in order for content to be classified as “conforming” to WCAG 2.0.

Conformance Requirement 4 states:

“Accessibility-Supported Technologies Only: Only accessibility supported technologies are relied upon to satisfy the success criteria. Any information or functionality that is implemented in technologies that are not accessibility supported are also be (sic) available via technologies that are accessibility supported.”

Understanding Conformance (WCAG 2.0)

When it comes to the use of JavaScript with forms, the following Techniques, which are supported by modern browsers and screen readers, may be useful:

“Providing client-side validation and alert: To validate user input as values are entered for each field, by means of client-side scripting. If errors are found, an alert dialog describes the nature of the error in text.”

W3C Description of SCR18 Technique

“SCR19: Using an onchange event on a select element without causing a change of context: The objective of this technique is to demonstrate how to correctly use an onchange event with a select element to update other elements on the Web page. This technique will not cause a change of context.”

W3C Description of SCR19 Technique

“SCR21: Using functions of the Document Object Model (DOM) to add content to a page: The objective of this technique is to demonstrate how to use functions of the Document Object Model (DOM) to add content to a page instead of using document.write or object.innerHTML. This technique is useful for inserting error messages at the top of a form.”

W3C Description of SRC21 Technique

For more information and techniques see the W3C Full list of Client-side Scripting Techniques for WCAG 2.0

Error Detection and Messages

WCAG 1.0 did not contain any guidelines that were directly concerned with the prevention and correction of errors. Addressing this issue with the following specific Guideline is one of the significant advances with WCAG 2.0:

“Guideline 3.3 Input Assistance: Help users avoid and correct mistakes”

This Guideline contains the following six Success Criteria that relate directly to error prevention, detection and correction:

“Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”

WCAG 2.0 Success Criteria 3.3.1 (Level A)

“Labels or Instructions: Labels or instructions are provided when content requires user input.”

WCAG 2.0 Success Criteria 3.3.2 (Level A)

“Error Suggestion: If an input error is detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content.”

WCAG 2.0 Success Criteria 3.3.3 (Level AA)

“Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true:

  • Reversible: Submissions are reversible.
  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.”

WCAG 2.0 Success Criteria 3.3.4 (Level AA)

“Help: Context-sensitive help is available.”

WCAG 2.0 Success Criteria 3.3.5 (Level AAA)

“Error Prevention (All): For Web pages that require the user to submit information, at least one of the following is true:” (Same as for 3.3.4)

WCAG 2.0 Success Criteria 3.3.6 (Level AAA)

The W3C provides many “Sufficient Techniques” and “Advisory Techniques” to help developers prepare forms that comply with the Success Criteria for 3.3: Input Assistance.

Techniques for Guideline 3.3 to Help Users Avoid and Correct Mistakes

Developers could find the following Sufficient Techniques, which are supported by modern browsers and screen readers, useful:

G83: Providing text descriptions to identify required fields that were not completed.

SCR18: Providing client-side validation and alert.

G85: Providing a text description when user input falls outside the required format or values.

G139: Creating a mechanism that allows users to jump to errors.

SCR21: Using functions of the Document Object Model (DOM) to add content to a page.

In general, when validation detects errors in a form, there is a 4-step process for ensuring usable and accessible error recovery:

  1. Alert the user to the presence of an error in an accessible manner
  2. Provide advice on how the error can be corrected
  3. Allow the user to easily access the form elements that need to be rectified
  4. Allow re-submission and re-validation of the form

Avoid using organisational jargon or code for error messages.

The following form provides a suggestion for how error messages may be presented in a useful and accessible way:

Screenshot of form 7

Form 7: Identifying errors and providing assistance

Screenshot of form 7a

Form 7a: Identifying errors and providing assistance

The “Error Detection and Messages” form uses client-side JavaScript to identify an error (for example failure to fill in the second number) and provide a description of the error at the top of the page. The error description is a link, which when activated moves the cursor (focus) to the matching form control so that the user can easily make the necessary correction.

The source code for Form 7 Error Detection and Messages contains the required CSS, JavaScript and HTML for the form.

This form works with recent versions of JAWS and Window Eyes. However, since a few people access the web with devices that do not support JavaScript, developers should ensure client-side error detection fails gracefully in circumstances where JavaScript support is not available or has been rendered inactive. This will include the provision of back-up server-side checking, which is equivalent to the client-side service, for users who do not have JavaScript.

Video 4: Error detection and message form

Self Populating Selection Options

Some forms contain several drop-down combo menus that use select elements, and the choice made in one menu determines what is presented in a following menu. This issue is addressed in Guideline 3.2 of WCAG 2.0

Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes.

WCAG 2.0 Success Criteria 3.2.5 (Level AAA)

Success Criteria 3.2.5 covers a number of issues, with Sufficient Techniques for each. In relation to the use of select menus that dictate the content of other menus the following Sufficient Technique is provided:

SCR19: Using an onchange event on a select element without causing a change of context

The following example contains two Select elements, “Region” and “Country”. When a Region is selected, for example Asia-Pacific, the Country choices for that region become available. If another Region is selected (eg Europe) then the Country choices are automatically updated to those that relate to the new Region.

Screenshot of form 8

Form 8: Form with updating Select element

Screenshot of form 8a

Form 8a: Form showing second Select element choices

JavaScript is used to allow the choices available in the second Select element to be dynamically determined by the first Select element choice.

This form works with recent versions of JAWS and Window Eyes. The source code for Form 8 JavaScript and Select Menus contains the required CSS, JavaScript and HTML for the form.

NB: Since some people access the web without JavaScript support, it is advisable to provide an accessible alternative way of obtaining the information that is available via this type of form.

Video 5: Form with dynamically updating Select

Show/Hide Form Sections

With multi-faceted forms it is sometimes useful to only show the relevant areas of the form. Banks and other financial institutions often have forms that contain a number of variables and the information the user is required to provide depends on which variable the user selects: For example, do you want a housing or personal loan? Or, do you wish to insure your car or boat?

There are considerable usability and accessibility benefits in providing the user only with the form fields that are relevant to their request. This can be particularly useful for people with cognitive disabilities and learning difficulties.

A combination of CSS and JavaScript can be used to show and hide different sections of a form. However care has to be taken to ensure newly shown form sections are available to screen reader users, while also stopping the screen reader from returning to the top of the page when a new section is presented. By default, when a page refreshes the screen will start reading from the top of the page.

This issue is dealt with in the following Sufficient Technique which relates to three Success Criteria:

SCR26: Inserting dynamic content into the Document Object Model immediately following its trigger element

The W3C provides the following description of this technique:

“This technique inserts new content into the DOM immediately following the element that was activated to trigger the script. The triggering element must be a link or a button, and the script must be called from its onclick event. These elements are natively focusable, and their onclick event is device independent. Focus remains on the activated element and the new content, inserted after it, becomes the next thing in both the tab order and screen-reader reading order.

Note that this technique works for synchronous updates. For asynchronous updates (sometimes called AJAX), an additional technique is needed to inform the assistive technology that the asynchronous content has been inserted.”

SCR26: Inserting dynamic content into the DOM

The following form contains a show/hide section which is determined by the radio button selection. If “cone” is selected the choice of cone sizes is presented. However, if “tub” is selected the “cone” size section is not presented.

Screenshot of form 9

Form 9: Show/hide form with Show section displayed

This form works with recent versions of JAWS and Window Eyes. The source code for Form 9 Show-hide contains the required CSS, JavaScript and HTML for the form.

Video 6: Form with a show-hide section

Timed Responses

Some forms have timeouts associated with them. For example, online transactions often use forms where a cookie or server-side variable is set to expire after a designated time or as the result of a period of inactivity.

Completing a form often requires the site user to carry out a number of separate tasks that involve reading and understanding instructions, making choices and then taking the appropriate action.

The setting of time limits for forms is likely to exclude some users with certain disabilities from completing the form in the required time. Where the imposition of a timeout period is not essential it should be avoided.

It is likely that people with cognitive disabilities and learning difficulties will take longer to read and understand written information. Also, it usually takes longer for users who rely on assistive technologies such as screen readers and input switches to access information on a web page and interact with forms.

This needs to be taken into consideration when setting server timeout limits and is specifically addressed in WCAG 2.0.

“Timing Adjustable: For each time limit that is set by the content, at least one of the following is true:

Turn off: The user is allowed to turn off the time limit before encountering it; or

  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: the time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.”

WCAG 2.0 Success Criteria 2.2.1 (Level A)

Success Criteria 2.2.1 contains the following “Sufficient Techniques” that developers might find useful:

SCR16: Providing a script that warns the user a time limit is about to expire: The objective of this technique is to notify users that they are almost out of time to complete an interaction and provide a mechanism to request more time.

SCR16 Technique

SCR1: Allowing the user to extend the default time limit: The objective of this technique is to allow users to extend the default time limit.

SCR1 Technique

G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit. The objective of this technique is to minimize the risk that users will lose their work by providing a checkbox to request additional time.

G133 Technique

The W3C advises, Success Criterion 2.2.1 “should be considered in conjunction with Success Criterion 3.2.1 which puts limits on changes of content or context as a result of user action.”

Mandatory fields

Many forms contain input fields that the user must complete. All users, including those with disabilities, should be able to easily determine which fields are mandatory, or required.

Colour alone should not be used to indicate mandatory fields. This issue is addressed in Success Criteria 1.4.1 (Use of Color) with the following Sufficient Techniques:

G122: Including a text cue whenever color cues are used

G14: Ensuring that information conveyed by color differences is also available in text

Often a symbol or the word “required” is used to indicate a field is mandatory. The symbol or word should be presented with the form control label, and inside the label element. It should not be presented after the form control (input).

When a symbol is used, the key to the symbol should be presented before the form and not at the bottom of the form.

Colours and Fonts

Some people with vision disabilities are unable to discriminate between certain colours or may not be able to distinguish text from its background if there is insufficient contrast between the two. In general, use colour very sparingly with forms, and if used there should be considerable difference in contrast between the text and the background.

In WCAG 2.0 the minimum requirement of ensuring sufficient contrast is Success Criteria 1.4.3:

“Contrast (Minimum): Text and images of text have a contrast ratio of at least 5:1, except for the following:

  • Large Print: Large-scale text and large-scale images of 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 incidental text in an image, or that are not visible to anyone, have no minimum contrast requirement.”

WCAG 2.0 Success Criteria 1.4.3 (Level AA)

The following Sufficient Techniques are provided for this requirement:

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

G18: Ensuring that a contrast ratio of at least 5:1 exists between text (and images of text) and background behind the text

G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults

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

G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text

G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults

NB: WCAG 2.0 use a different algorithm to that used in WCAG 1.0 for determining the differences between foreground and background colours.

Also, some users find the default font size on websites is often too small for comfortable reading. This only becomes a major problem if the user is unable to increase the font size with their browser, so relative font size attributes should always be used. With forms, you need to ensure that when the font size is increased in this way the text and different elements don’t overlap.

This issue is addressed in the Sufficient Techniques for Success Criteria 1.4.4:

Resize text: Text (but not images of text) can be resized without assistive technology up to 200 percent without loss of content or functionality.

WCAG 2.0 Success Criteria 1.4.4 (Level AA)

References and more information

Conversation with Molly Holzschlag

by
, , ,
Reply

Molly Holzschlag and Roger Hudson discuss web standards, interoperability, HTML5, IE8 and web professionalism at the Webstock Conference in New Zealand.

Video and audio versions of Molly’s Webstock presentation, “Why Web Standards Aren’t” are available on from the Webstock site.

Molly Holzchlag in conversation with Roger Hudson, Webstock 2008

Duration: 19:42
February 2008, Wellington, New Zealand.

Molly Holzschlag Interview Transcript

[SHOT OF CONERENCE VENUE: Mike Brown introduces Molly]

TITLE: Molly Holzschlag in conversation with Roger Hudson, Webstock 2008

Roger: Nice to see you again Molly and welcome to Webstock 2008!

Molly: Well, thank you very much.

Roger: Is this your first trip to Wellington?

Molly: It’s my very first trip to New Zealand, yes and it’s just fabulous, I’m enjoying it.

Roger: The conferences been going well?

Molly: Oh I’m really enjoying it, but one of the things that’s really special about it I think is that is that it’s got a great sense of passion and this unity of who we are and what we are in the web and workers of the web, I’m liking that passion a lot. I’m also enjoying the fact that there are speakers here from all over the world many of whom you know who are colleagues of mine for many years, and the fact there are a lot of local people and so it’s really bringing a lot of different people together, so it feels very much of a “webstock”, – you know like a get together of very diverse individuals with one greater common goal which is to make a very useful web and continue on innovation for the web.

Roger: In your presentation you draw distinction between standards and best practice what did you mean by this?

Molly: What I mean by that is that when we talk about web standards, I am challenging the language of that, I am suggesting that what we are doing really aren’t true standards like a manufactured standard for example which is, a good example would be a safety feature within your automobile. There have to be certain levels of safety features in each automobile before that manufactured item is able to ship and the law oversees this throughout the world. So there are international standards for that sort of thing, what this allows for, is for interoperability and quality and a level of security for the individuals in terms of what they are selling. We don’t really have anything like that in the web, what we have is a collection of specifications and recommendations that come out of the W3C as well as some other organizations depending on who we are talking about, for example Javascript is actually being standardized under ECMA. So the W3C itself, the technologies that we see there such as XML, XHTML, HTML and CSS and all the various languages that we mostly work with as the lingua franca of the web, are specifications and recommendations, these are not standards in the truest sense of the word. When we talk about W3C specifications and recommendations, there is no real mechanism to check other than conformance, so if I write an HTML document I can validate that document. But that doesn’t necessarily mean that what is valid and conforming is what is useful, usable, accessible and really works. That all comes into this ideology that we have termed web standards, (the term really emerged out of the Web Standards Project) where the idea was really about best practices and how to use these specifications and guidelines and recommendations to create great websites that are living to this ideal. I can create a website that validates and that doesn’t live to this ideal very easily okay, and so I think it’s just very important that we make the distinction that what we are really trying to achieve when we achieve web standards is actually a level of professionalism.

Roger: So in all of this, how important is interoperability?

Molly: Interoperability is the most important thing in my opinion when we look at the web and the vision that it was meant to be, was that it would be any platform, completely platform agnostic, completely user agent agnostic so, in other words whether I’m using my little PDA device or I’m sitting at a huge screen at my computer station that I should be able to access that data and this is where interoperability (software interoperability) it means that the information data that I’m sending, can be viewed in some way by all of these devices. Now the web is really meant to be that way and it can be that way, the problem is that these best practices have not necessarily been applied or adopted at a rate in which we would like to see it, a lot of that is educationally related, there are problems in education and tools and things of that nature. Building websites is really not an easy thing to do, and so interoperability is what we need in order to get back to what that grand vision was originally so that we use our best practices in order to create that interoperability, but we also need in terms of our software we need that to be interoperability where we see the worst problems and the most challenge there as within the browser, so which browser is doing what is going to determine how we work. Which actually adds a layer of extra work for everybody that really shouldn’t be there.

Roger: So without a greater commitment to interoperability, is the concept of web standards relevant still?

Molly: I think that web standards are a part of the commitment to interoperability, it’s sort of , somebody put it very well when I was asking for public definition on my blog about what people thought web standards were and he said “Standards are putting the cart before the horse”. So the two are intertwined, but until peoples skill sets balance out, until there are some more of us of a professional standard involved, and I think we are going to be at odds with the interoperability issue because we have difficulties in getting the different companies to decide they want to work together and lease those baselines and compete in other areas. If we go back to the analogy of the car, what I would say is that various user agents (the browsers), need to be promising each other that baseline commitment to certain aspects of specifications and what we would like to be standardized within browsers are there, that is their baseline, everybody follows that baseline and then innovation is built on top of that.

Roger: Is the explosion of mobile devices bringing us to a crisis point now?

Molly: I think that point of crisis has been with us since 1994 actually, as soon as the web became visual. Naturally, we can’t necessarily look at all of that and go “oh! this is a terrible thing” because of course it advanced the web, it made the web very useful for people right away, but what happens is again “the cart before the horse” we were building very complex websites without really understanding what was going to happen over time as they needed to scale, as they needed to be modified as they needed to be managed for the long term, as they began to grow right, so we have all of these challenges now in the infrastructure that came out of this experience in this huge burst of growth, you know, in the evolution. But this is part of evolutionary technology and we have to I think accept that, but we have also to be involved and constantly learning and improving and really caring for our profession.

Roger: 1994 also was the year of course that the W3C came into existence. It seems they deliberately avoided, when they were setting up W3C, to have any responsibility or control, they sort of shunned the notion that it was going to be an organization that would somehow be in control of the web. Was that a right decision back then do you think?

Molly: I think it’s really a philosophical issue, because the web is supposed to be an anyone anywhere other people kind of thing, the democratic vision, if you will, is part of that decision and I don’t want to see that changed, I think that’s beautiful it should be that way every person should be able to have their say if they wanted. And that’s really some of the value – it has tremendous amount to do with the value of what we have on the web today. So I think that “No it was not inherently wrong for them to take that ideology”, but what never really seemed to emerge was a professional, a very strong professional industry organization and we start seeing little ones coming up in different areas, Australia for example, here in New Zealand there is a web standards new Zealand there is various groups around the world that are starting to do this professionalism. None of these things really ever rose to that position where there is a professional organization that could be helpful to the people in the web profession, by providing educational resources, by providing different things that such professional organizations do.

Roger: Not wishing to sort of belittle the democratic side, but also since 1994, the Web has grown a hundred fold. Maybe it is time – I can’t help feeling – that someone was responsible; there is a need for a responsible organization:

Molly: I think yes, and I think we’re going to start to see that happen, but it’s not going to be one organization. As you sit through this conference we see that. For example Simon Willison was talking about OpenID and the various groups that are working together; this is what we really have to see. We have to see different specialities coming together in this huge mashup of technology and creativity. And I think that in order to sustain that we’re going to need to have little pieces of the pie come together and make up the whole thing. So the W3C will always have a role, I hope, but certainly its infrastructure can improve but, again, I am an advocate for professional organizations, I would also like to see some external to W3C, non partisan groups come up so that interoperability issues can be discussed freely amongst various browser vendors without the agenda’s getting in the way, so be they adjudicated or something of that nature.

Roger: In recent times, the development of HTML 5 has generated a whole lot of heat, has there also been a bit of light do you think?

Molly: A whole lot of heat?

Roger: Yeah, a whole lot of arguments and passion.

Molly: Ah, arguments and passion. I think HTML 5 certainly, when you look at it as a spec, it’s really fascinating. I mean we’re really moving away from just a markup language, to a language where there’s the creation and the relevance of API’s and all of this, so, you really have to look at it as something different. I think it’s an evolutionary, again it’s an evolutionary step; the way that people in the HTML 5, well originally the WHAT Working Group before HTML 5 came under the auspices of W3C, the folks in the WHAT Working Group really set things such as HTML 5, if it were coming out right after HTML 4.01, it probably would have been a progression, but now, it’s like a reworking of HTML because of all the different things that have happened, and the focus on application development. So we’re looking at in HTML 5, at a lot of things that will empower us on the client side with applications so that’s really good. But, the implementation part is going to be where we’re going to see problems. A good example is client side storage, right. So I mean, that’s a very, very good idea and HTML 5, a whole part of the spec is based on how to do that, but who’s going to implement it? You’re going to see again, the disparities here, and this again turns into a competitive issue on the functionality and the baseline of a browser and that’s not where the competition should be. So, there’s no unity in that piece, and that’s where interoperability in the software gets lost, and I’m very concerned about that. So whether it’s HTML 5 or whether it’s JavaScript, we also have an issue with JavaScript right now – in browsers and browsers evolving along different paths. I really would hope to see some point where the user-agent implementers get together and get those baselines into place; agree on those baselines, abide by those baselines and then find their own ways to compete.

Roger: Do you think some of the lack of communication has led to, I know a lot of people in the accessibility community have been very upset by some of the stuff in HTML 5

Molly: Well, it’s something very specific, it’s really for the canvas issue and other things in HTML 5 that accessibility folks are worried about and I think… where you have that, you have… There are problems in the HTML 5 process from the get go. You heard me speak about the authorship as being largely driven by one single person, so this isn’t to say that there aren’t collaborators and it’s certainly under the W3C. There are a lot more people involved in a more formal way. But, the fact of the matter is that the majority of the spec was written by one person and a handful of supporters, and that would be Ian Hickson and he’s also the person that has written Acid2 and Acid3 tests. Certainly a very bright guy, but it worries me that one individual would have that much sway over a given specification when they are not working toward an interoperable environment. I think that’s more critical so that if it’s only one person, that also means one agenda and I don’t know what the agenda is, though I’m sure to Ian, it’s making the best Web that it can be because he’s a very hardworking dedicated person. But I don’t think that is the way specifications should evolve and I don’t think it’s going to help with interoperability because it cuts the dialogue and it creates cabals, right. It creates these separations where “I’m with these guys” and “I’m with these guys,” and “but, no, I’m over here”. So there’s separation not integration. That’s a huge part of the problem.

Roger: I want to look for a moment at the recent sort of area of the development of IE 8. What’s been going on there?

Molly: Okay, so essentially what I can tell you a little bit about, in so far as my understanding of the hot topics of IE8 and what’s going on there, is that we’re seeing a shift away from the ‘Trident’ engine. So the ‘Trident’ engine has some core problems with it. It’s an older engine, of course there wasn’t any change or innovation for that long period of 5 years, and that caused a tremendous problem for Microsoft in terms of software, engineering, and trying to figure out how to catch up with everybody else. So one of the things that they have done, is that they’ve now begun to create a very strong engine, that is capable of supporting in this case a lot of stuff, like all the CSS 2.1 stuff, Acid2 rendering, and all that, so a tremendous amount of support for things in IE8 but there’s still these legacy issues and for Microsoft, that’s a critical piece because so many intranets, and so many public websites have been built using that as the model. What Microsoft risks, is that it will “break” the Web if it changes its browser too abruptly. So what ended up happening is an opt-in switch. So that individuals, so the creation of this opt-in switch if you add a meta element that says if I want my browser to operate in compliance mode, which is the standards mode, very similar to something we used to have, not used to have, it still happens in doc type switching, standards mode and quirks mode, basically, this is a different level of that; a different layer of that; where if we have the meta elements in there, then we can force that browser to render in the best way possible. Otherwise, it’s going to default to an earlier version, probably IE6, I’m not clear yet whether that is factual, but that is what I’m led to understand at this time: Which of course has caused some very big concerns in the industry. Why isn’t it going to default to whatever the latest and best would be beneath that, but this has to do with the ‘don’t break the Web’ ideology in the IE group within Microsoft because they have that responsibility to many, many billions of customers.

Roger: The last few years, there’s been a huge boost in social networking sites, is that presenting us with some challenges?

Molly: Oh well, I think clearly it does. I mean when you talk about security, you talk about identity, all of that comes into play so what’s really fascinating about social networking to me is that it is extraordinarily powerful, and yes, in the wrong hands, extraordinarily dangerous. So we have to be very responsible I think, again, this is where I’m hinting at the idea professional organizations that set a level of professional standards for people working in the industry that say we’re only going to do these best practices because we want to keep the Web safe. You saw Simon talking a little earlier about OpenID and some of the ways they are doing that through encryption. So, there are some technologies out there that are really going to assist us with that. But, there are a lot of concerns no doubt.

Roger: So how do you see the web developing over the next few years?

Molly: It’s interesting because I’m not a fortune teller; not a very good one anyway, and I tend to be leery of making predictions, but one of the things that I think is certainly going to happen is that we’re going to see clearly a lot more video, audio, more mashups, and more complex things happen technologically, and perhaps I hope a great improvement in user experience. And, of course with more broadband over time that even will increase more. But, my concern for the future has less to do with what is actually going to end up in the technological realm, than what is happening in the professional side of things. We need to keep the community learning, we need to keep the passion alive, we need to keep the ideologies alive, and that happens through social network, through conferences such as Webstock, bringing the world together in a greater ideology of professionalism. Because if we have professional understanding and set the bar higher for us, ourselves, then we are challenged to create better things; to solve problems more efficiently, and to create more innovative products. So I think that’s really where the focus is, it needs to be on the education, the community, the social network and the professional network as we move ahead – supporting each other via community.

Roger: And, what’s next for Molly?

Molly: I think a couple of days of rest.

Roger: Many, many thanks for your time today.

Molly: Thank you so much

Roger: And thank you very much for a great presentation

Molly: Thank you, it was truly my pleasure

Roger: Thank you.

Interview with Shawn Henry (W3C)

by
, , ,
Reply

Shawn Henry, from the W3C, was a presenter at Webstock 2008. During a break in the conference, she talked with me about how she first got involved in website accessibility, the need to continue breaking down some of misconceptions associated with accessibility and the Web Content Accessibility Guidelines (WCAG) Versions 1 and 2.

Video and audio versions of Shawn’s Webstock presentation, “Make Your Website Shine, Polished with Accessibility” are available on from the Webstock site.

Shawn Henry in conversation with Roger Hudson, Webstock 2008

Duration: 10:58
February 2008, Wellington, New Zealand.

Shawn Henry Interview Transcript

TITLE: Shawn Henry in conversation with Roger Hudson, Webstock 2008

Roger: Hi Shawn. Welcome to Webstock 08.

Shawn: Hey Roger. It’s great to be here.

Roger: And how’s the conference been, do you think?

Shawn: It’s been really good. I get to be involved with workshops starting Monday morning. And so all the way through this week it’s just a great bunch of people organizing it and really neat opinions and thoughts brought in together. It’s fun.

Roger: So, how did you get started in the area of accessibility, Shawn?

Shawn: Well, I was actually in user interface design, so designing mostly software and got into web when I started having some problems myself. So I had visual problems and wasn’t even able to sit up at the computer long enough to work. And, so I thought I was going to have to give up and not work anymore. And I discovered accessibility and I happened to live in a place where there’s a Trace Research and Development Center that studies accessibility and has been for some time. So I decided to do something about it. And even after I went into remission and was doing better, once I learned the importance of accessibility and how much it can change people’s lives, that was it. I’m sticking with it.

Roger: And then on to the W3C?

Shawn: Yup. Yeah. So, I got into accessibility more than ten years ago and I was integrating it with usability and doing some consulting on that. And then I was really looking at how I could have a more global impact on accessibility, and the W3C was a place for me to do that. So I’ve been there for five years.

Roger: Why do you think it is that still there are people who view accessibility in a negative light? Why is that?

Shawn: There are so many misunderstandings. Early on, in fact, you could not make your site accessible and visually appealing and dynamic. So, years ago, there was some truth to that “myth”. For many years now, that’s what it is, it’s a myth. You can still have a site that is beautiful, that is cutting edge, that is dynamic and make it accessible. But one of the problems is there aren’t enough good examples of that.

Roger: In you presentation today, “Make your Website Shine Polished with Accessibility”, you actually talked about misconceptions a bit. Is that to sort the myths?

Shawn: Yeah. That’s one of the huge ones, is that accessibility is dull and boring. That’s one of the myths and misconceptions that we need to get past. And I think we’re doing better, there are more examples, but I really want to challenge designers to provide us with more examples of sites that are beautiful and accessible. And that’ll really help the field move forward.

TITLE: Web Content Accessibility Guidelines (WCAG)

Roger: Since the introduction of WCAG One in 1999, do you think there’s been a general improvement in the accessibility of websites?

Shawn: I think there has been an improvement in sites since 1999. I think part of it was because these guidelines were available internationally. I think part of it is because of some of the government regulations around the world that had been put in place. Certainly, the web is a lot more accessible now than it was then. But there’s still a lot to be done. While there are sites that are working on some really neat aspects of accessibility and there are sites that have included accessibility in their redesigns, there are still so many sites on the web that aren’t doing even the basics, even the simple things, as you know. And that’s sad to me you know, that even the simple things aren’t being done. So it’s better, but we’ve got a lot to go.

Roger: One of the really interesting things I noticed of the audience today is a reaction to your talk when you started talking about it’s not just about people with disabilities, that for everybody, good sites, accessible sites brings benefits.

Shawn: Absolutely. Yeah. When I was selling accessibility several years ago, when most people didn’t know about it, we would talk a lot about the additional benefits, you know the business benefits, the technical benefits. Right now, we can talk about the overlap with making your site work better for different mobile devices and search engine optimization. And there were some, a few people who said, “Well, that’s watering down, that’s limiting the importance of access to people with disabilities.” And, I think it’s great to talk about them together, because absolutely, accessibility should be done because it’s vital and it’s important and it’s the right thing to do. But when we can understand all the additional benefits to everybody, then we can just put it on a higher plane. We can get more time and budget to consider accessibility when we realize it really helps everybody.

Roger: So Shawn, what are the major differences, do you think, between WCAG One and WCAG Two?

Shawn: There’s a couple of different things. One is that WCAG One was developed in a world where we focused a lot on HTML. WCAG Two has been developed to apply more broadly to different technologies now, and to be able to apply it to different technologies in the future. So, with WCAG Two, we have the basic guidelines themselves, which are intended to become a W3C recommendation standard. And then we have the supporting documents, like the techniques documents which tell you how to implement WCAG in different technologies and different situations. So WCAG 2.0 itself is really designed to be more applicable to different technologies now and in the future. Some of the other things that are different are the testability. One of the issues with WCAG One is that it wasn’t clear sometimes for certain provisions whether a website met WCAG One or not. So with WCAG Two that’s been a key factor. We really want to make it clear. We have Success Criteria now to make it clear when you have a website that meets accessibility guidelines. What that guideline is, what that Success Criteria is, and how you can meet that, that’s much more clear.

Roger: With WCAG Two, we introduced the concept of Accessibility Supported. What does this mean? It’s a little unclear to some people.

Shawn: Well Accessibility Supported is one of the ways that we allow the guidelines to apply now and in the future, to apply in specific situations. Basically what it says is, in order to meet WCAG, in order to provide accessible content, you need to use technologies that are accessibility supported. You need to use technologies that work with assistive technologies and work with the accessibility features of browsers and other user agents. So, that’s the concept. Now, some of the benefits of that, you can have web content use different technologies in certain situations. So for example, if I’m developing an internet application that everyone needs to access, I can’t rely on SVG, because not everybody has SVG player, right? However, if I’m developing an internal application just for within my company and I know everybody has access to a SVG player and they have the tools so that it’s accessible, then I would be able to use SVG in my content.

Roger: But as we’ve mentioned already, in terms of WCAG One, these guidelines did become sort of enshrined in legislation or recommendations from different governments. Do you see any sort of jurisdictional problems, with one country having, setting, one level of accessibility supported with another on the internet?

Shawn: I think it’s certainly something that we’re going to need to look at and see how it plays out. Because we allow this flexibility, we’re going to need to work on how we can define that and how that can benefit accessibility, benefit developers and be a positive thing and not a negative thing. So, I think that is something we are going to have to work on, we’re going to have to watch.

Roger: Just changing a little bit. With social networking sites like Youtube and Myspace, where do you think the responsibility for accessibility lies in these sites?

Shawn: I think it’s very broad. As I mentioned in my talk you know, accessibility is partly the role of the content developer, partly the role of the browser, media player, user agent and assistive technologies, but also the authoring tools. And so, there things that these tools can do, that the sites can do, to help encourage accessibility, as well as just allow it. I mean, some of the sites don’t have any provisions for adding accessible content. So, even if I am adding content and I understand accessibility and I want to make something accessible, I can’t! So the first step is allowing that, the tool allowing that. And the next is going further and actually encouraging it; so when the user puts content on, asking them for whatever is necessary for accessibility.

Roger: So it’s a sort of shared responsibility, the person generating the content and the site or tool that makes it possible?

Shawn: Absolutely, yeah. Definitely shared responsibililty. The first step is the tool has to make it possible and encourage it. And then we can work on educating the people who are putting the content on.

Roger: So, what lies ahead Shawn? Do you think there will be WCAG Three?

Shawn: (Laughs) We have talks about this, yeah we’ve been talking about what lies ahead next. I think it is going to be really interesting to see what we do now that there is such a convergence between content and user agents and authoring tools, you know, we were just talking about using authoring with really web content mixed together. So I am not sure there will be WCAG Three. I think there will be guidelines three, but maybe they’ll be all combined, we’ll see.

Roger: Many thanks for your time Shawn. And thanks for a great presentation at Webstock 08.

Shawn: Thanks so much Roger. I appreciate the time to talk with you.

Wheeling in Second Life

by
, , ,
Reply

Judith, who has cerebral palsy, has been using computers and the web for many years. Recently she was telling me about how much she was enjoying Second Life and so I asked her if she would mind showing me it. In the video, Judith talks about using Second Life and a club called “Wheelies”, which is one of her favourite locations.

Wheeling in Second Life

Duration: 4:27
December 2007, Sydney.

Wheeling in Second Life video transcript

Judith: I work during the day, so when I come home I’ve only got like a couple of hours. So by the time I do my own emails and correspondence that come in during the day I might have forty-five minutes or an hour to do whatever, so

Roger: And what’s your current really big thing on the Web that you’re into?

Judith: Second Life. I’ve got a wheelchair in Second Life also. You can choose whether you want to be in a chair or not. You can have crutches, you can have whatever disability you have in real life in Second Life.

Roger: Do you always stay in your wheelchair in second life?

Judith: No, no, no.

Roger: Are there many other people in wheelchairs in Second Life?

Judith: Simon Walsh.

Roger: From the UK?

Judith: Yes. And he always stays in his wheelchair. But, just like in real life, I find the attitude of people in Second Life to people with disabilities (is disappointing). I have run an experiment myself. I’ve gone to this particular website as an able bodied person, got out on the dance floor and danced for half an hour with different avatars or different people, or whatever you call them. Then I’ve gone away, put myself in my wheelchair, gone back, the same people were there and they didn’t want to know me.

Roger: Are there special places in Second Life where people in wheelchairs hang out.

Judith: Yes, “Wheelies”.

Roger: And what’s Wheelies.

Judith: That’s a nightclub specially built people, by a man who has cerebral palsy, in the UK.

Roger: Can you take us to it?

Judith: Yes.

Caption: Wheelies was started by Simon

Judith: Unfortunately like real life you’ve got to go around things because you can’t go through them. You can fly over them. Oh, there’s Simon!

Roger: He’s in there is he?

Judith: Yes. He was there before, in there [typing question with headwand]

Caption: How many people visit “Wheelies”?

[On-screen dialog: (asking how many people visit Wheelies each week) Simon: “Wheelie or norm?” “Few 100 I guess”.]

Judith: There you are; one hundred people a week. When I first started we got a couple of hundred.

Caption: Going up to the dance floor.

Judith: That’s Simon up there, the avatar… [looking to other screen] that’s him in real life.

Roger: And he was on Big Brother?

Judith: Yes, in the UK. [turning towards dance floor] And that’s the DJ, that girl in the green, she’s the DJ, and he pays her to be the DJ there.

Roger: Oh, right…

Judith: And she talks to you over the thing there saying hello Wheelies … see she’s talking to you.

Roger: do you think that this will be a really useful tool for people who are unable to get around, who have problems of mobility in real life?

Judith: Yes, because you can have friends without having to go out and physically find them.