Web Standards Group - WSG

Home - WSG interviews

Ten questions for Gian Sampson-Wild


Gian Sampson-Wild

Gian Wild has worked in the accessibility industry for over seven years. She ran the accessibility consultancy PurpleTop for five years and built the automated accessibility testing tool PurpleCop. Gian worked as the accessibility consultant for the Melbourne 2006 Commonwealth Games for over two years and trained Microsoft developers on how to maintain the accessibility of the site. Gian has been a Member of the W3C Web Content Accessibility Guidelines Working Group for over six years and has spent a significant amount of time working on WCAG, Version 2.0.

[1] Russ: You have been involved in accessibility for a long time. How did you get started?

Gian: In 1998 I was working for a small Lotus Notes web development firm called KnowledgeWorks. We were hired by the Vision Australia Foundation to build their web site and to our surprise they wanted their own clients to be able to access the site. We knew nothing about accessibility, and the W3C had yet to release the Web Content Accessibility Guidelines so we just did a lot of research and user testing to make sure the site could be used by people with vision impairments. That led to the development of the Disability Information Victoria web site (now Disability Online) for the Department of Human Services which was the first Victorian Triple-A web site. KnowledgeWorks was bought by Sausage Software in 2000 and about a year later I was retrenched. It was then that I decided to begin my own accessibility consultancy, PurpleTop.

[2] Russ: What do you find are the most challenging aspects of web accessibility?

Gian: By far the most challenging aspect of web accessibility is convincing managers and developers to incorporate it into the costs or the build. I don't believe web accessibility is difficult to achieve if people approach it as just another business requirement. Perhaps the site would be easier to build if you didn't need to worry about web accessibility, but then a site would be easier to build if it was all text as well, and not many people think that's a viable option anymore! Accessibility is just one of a myriad of best practice requirements, like information architecture, usability, content development and testing.

[3] Russ: I have heard rumours that you have been involved in the development of WCAG 2.0? Is this true?

Gian: Sometimes I wish it wasn't true! But yes, I have been on the Web Content Accessibility Guidelines Working Group for six years. As a Member of this Working Group we have been writing WCAG 2.0 along with Techniques documents. It's a grueling volunteer position - we have teleconferences every Friday from 6am! Unfortunately there are many decisions the Working Group has made that I personally disagree with.

[4] Russ: OK, let's cut to the chase... Will WCAG 2.0 be easier for developers to follow and adhere to than the current guidelines?

Gian: WCAG 2.0 is not complete yet. Last Call has just finished and it is possible that there will be a great number of changes to the document before it supercedes WCAG 1.0. However if WCAG 2.0 were released 'as is' I don't believe it will be easier for developers to use than WCAG 1.0. WCAG 2.0 is not technology-specific (WCAG 1.0 was specific to HTML and CSS), and therefore there is a lot of jargon - like the term 'web units' to define a web page, or how checkpoints are now called 'success criteria'. I'm still not sure what 'programmatically determined' means! In addition to this, there are some real challenges because complying with WCAG 2.0 won't necessarily mean that a site is accessible.

[5] Russ: Hold on a minute! Are you saying that even if developers follow WCAG 2.0 that their site won't be accessible?

Gian: Yes, unfortunately, even if a developer follows a reasonable baseline then a WCAG 2.0 compliant site may still not be accessible to people with disabilities. One major problem with WCAG 2.0 is that a lot of very important success criteria have been outlawed because they don't fulfill Working Group requirements. For example, the WCAG 1.0 Level A checkpoint "Use clear and simple language" does not have an equivalent in WCAG 2.0 because it does not fulfill the Working Group requirement of 'testability'. Any success criteria in WCAG 2.0 must be 'testable', which means that either a machine can determine whether the site passes or fails, or eight out of ten human testers would agree on whether the site passes or fails. The clear and simple language checkpoint was deemed too subjective, violates this testability requirement and therefore has not been included in WCAG 2.0, despite being a very important requirement for people with cognitive disabilities.

[6] Russ: I heard that there has been an objection made about how WCAG 2.0 doesn't include enough cognitive disability success criteria. Is this true?

Gian: Yes. Lisa Seeman, a colleague of mine on the Web Content Accessibility Guidelines Working Group, lodged a formal objection to the WAI Steering Committee and the Working Group. I and some other members of the Working Group cosigned the objection. The objection details how WCAG 2.0 does not fully address issues faced by people with cognitive disabilities and requests that the W3C release a statement that WCAG 2.0 does not include sufficient success criteria to assist people with cognitive disabilities. The objection is available on the WCAG Working Group Mailing List.

[7] Russ: Can you tell me what this new WCAG 2.0 "Baseline" is all about? Who sets a baseline and at what level can a baseline be set?

Gian: WCAG 1.0 defined an accessible site as being HTML or text. Therefore you could provide information in alternative formats (such as images, PDFs, Flash etc) but there must always be an equivalent version in HTML (such as an ALT attribute, HTML or text file). However WCAG 2.0 allows a site in any format, if it has been defined in the baseline. For example, a Flash only site (without any HTML alternatives) would be WCAG 2.0 compliant if Flash is in the baseline. It is important to note that baseline is a set of technologies, not a set of products. For example baseline could specify javascript and Flash but not IE 5.0 or JAWS 6.0.

I have no problem with baseline as a theory. In theory, a Flash site should (one day) be as accessible as an HTML site; if it provides all the accessibility features that HTML provides, such as ALT attributes, valid code, links and separating presentation from content. However, until that day, the only way a Flash site can be accessible is to provide an HTML version of the same content. In WCAG 2.0 that is not required. In WCAG 2.0 you only need to make the site as accessible as the baseline will allow. This means that a site with a high baseline will be WCAG 2.0 compliant even though people with disabilities may not be able to use the site. This means that the site could still be discriminating against people with disabilities and therefore the site's owner may be liable to litigation.

Baseline can be set by developers or by governing bodies such as HREOC. It is up to each Government as to whether they set a baseline for their country or not. It's too early to speculate on HREOC's position on baseline.

[8] Russ: Speaking of speculation, is it true that valid code has become an option in WCAG 2.0?

Gian: Yes. This is another problem I have with WCAG 2.0. Valid code is important for assistive technologies to interpret web sites; one reason assistive technologies lag behind browsers is because of the tag soup most web sites present. Instead of valid code, sites must now be able to be "parsed unambiguously". This means that all start tags must have relevant end tags and that tags are nested hierarchically, however it doesn't require that mandatory attributes are included in relevant tags. It's pretty confusing which is one problem I have with it. It's also almost impossible to test.

[9] Russ: Well at least conformance seems the same. Do the levels (A, AA and AAA) mean the same as they did in WCAG 1.0?

Gian: No. The Working Group has released a statement that all success criteria are essential for some people with disabilities. This means that in WCAG 2.0 the three levels - A, AA and AAA are a categorisation of success criteria based on requirements such as testability, and not on how much they help people with disabilities. I have actually lodged a comment requesting that the levels in WCAG 2.0 are re-named so that people don't confuse these levels with the prior WCAG 1.0 levels. If you want to make your site accessible you need to look at all the success criteria in WCAG 2.0.

[10] Russ: Finally, what's in the pipeline for you? Books, movies, opening shopping malls?

Gian: I will be keeping a close eye on the 122 comments I made on WCAG 2.0 (apparently that is a record number of comments on any W3C Working Draft from one person!). Other than that I'm free to open shopping malls every second Thursday of the month.

Russ: Thank you for the interview, especially on such a tough topic!
Gian: Any time. I welcome any opportunity to talk - about any topic!

Copyright © Web Standards Group 2012