A Sea Change for Accessibility (Posted July 23, 2006)

There are some exciting changes in the air for accessibility in general and web accessibility in particular. Both WCAG
and Section 508 will be revised, there is a key legal case relating to accessibility that has just been hears, and
Google lets you search for accessible pages. Here is a brief synopsis of those developments together with links to
get more detail.

Section 508

NFB vs Target

There was a hearing on July 23, 2006, in Superior Court of the State of California, Count of Alameda, relating to the
suit of the National Federation of the Blind (NFB) against Target Corporation
(Case No.: C06-01802 MHP).
The suit has been brought by Disability Rights Advocates, in Berkeley, California.
The hearing (and the Court) will address two motions. The first is Target's motion to dismiss, the other is the NFB
motion for preliminary injunction. Other court cases involving the ADA and Web Accessibility have not yielded useful
opinions as to whether public web sites are subject to ADA requirements for access by people with disabilities.
This case probably will result in such an opinion. DRA has a discussion
of the suit on their site. I am the expert witness for the Plaintiffs, and in that role have submitted a report
on Accessibility of Target.com and a Declaration (tagged
PDF) (HTML).
The report is included as an exhibit at the end of that declaration. Chuck LeTourneau,
Co-Chair of the the Working Group that produced Version 1 of the Web Content Accessibility
Guidelines is the expert witness for Target Corporation. Letourneau also submitted a declaration
(untagged PDF) (HTML).

Google's Accessible Search

Perhaps the most surprising of these changes is the announcement by Google they have a new Google
Accessible Search. That may sound like they have a search page and it is accessible. Well ... the label for the
main search form is the text, "accessible search" with the style, display:none. This is a technique that
works with screen readers, but I wonder why they didn't use the same title="accessible search" as they do
on their main search page. From reading their Frequently
Asked Questions about the Accessible Search, it seems that pages which are simpler and which conform
to the Web Content Accessibility Guidelines will placed high (early) in the
search results. That being the case, it is troublesome to me that the Accessible Search page is highlighted as "Accessible
Web Search for the Visually Challenged" - I would just leave out the awkward "for the Visually
Challenged," or better call it "Google Search for Accessible Pages."

Accessible Search is a pet project of T.V. Raman. Formerly of IBM
Research, Raman is the creator of Emacspeak, a complete
audio desktop for Unix. In his Google blog
post on the accessible search, Raman says that the results will be "prioritized based on their usability." More
about the Accessible search on the Google Blogoscoped, in particular there
is a simple interface to compare results of the accessible search
and the normal search. For example, try searching for "google" there. Google's own search page doesn't appear
in the top 10 under the accessible search.

hasLayout Property
Characterizes IE6 Bug (8/15/5 - modified 8/28/5)

The target of the skip link on this page used to look like this:<table><tr><td>
<a name="cont" id="cont"></a>
</td></tr></table>

"Why a table?" you should ask. The answer is that there is a bug in Internet Explorer Version 6.0
which causes in-page links to not work from the keyboard. But when the target of any in-page link
is placed at the top of a table cell then it will work correctly from the keyboard with IE6.
What does work correctly mean? This description seems to be daunting for web developers who are so
focused on and dependent on the mouse. Here is how to test any in-page link:

Hide the mouse so you don't mess up this experiment.

Use the TAB key to move to the in-page link that is to be tested.

Press ENTER; that will reposition the visual focus on the page so that the
target of the in-page link is at the top of the visual window (if there is enough of a page to refocus).

Now, and this is the key, press TAB again. This time the TAB key should move to the first link below the
target of the in-page link. Often this is not what happens; instead this TAB puts focus
on the first link of the page, or generally some other unwanted place.

If you follow these steps with Netscape 7.2, Mozilla Firefox 1.04 or Opera 7.54
(substitute the A key for the TAB key in the process of testing the links in Opera) everything
will work as one would hope and expect; not so for IE6.
Mike Cherim has created a terrific set of three pages called
A Focus on Focus
with which you can run this experiment.

For table-based sites like CNN
and IBM (as of this writing), the skip links usually work because
it is natural for the target of the link to be at the top of a table cell (td).

For more contemporary sites like that of the Web
Accessibility Initiative of the World Wide Web Consortium,
for example, the in-page links do not work.
Try WAI home page.
TAB to the "Skip to Content" link, press ENTER and visual focus moves, but TAB again and input
focus is back at the top of the page. It should work but it doesn't - at least as of this writing.
This is true of many sites, and not just skip links. For example I have a short "table of contents"
at the top of my comparison of Section 508 and WCAG.

Though they are fixed now, up until recently if you activated one of those from the keyboard,
then tabbed again, you were back at the top of the page.

What is the solution (read work-around) for this problem? Through discussions
on various mailing lists over several months the nature of the IE6 bug
has become clearer.
In May of 2005 Becky Gibson (IBM) and
Mike Scott (MSF&W) independently recognized that when targets of in-page
links were contained in (actually at the top of) elements "with width defined" (whatever that meant) - they
generally worked from the keyboard. It was Terrence Wood who put it together
with the hasLayout
property:

IE6 places input focus on the first ancestor object of the target of the link
which is a
span or div with the property hasLayout set to true or which is one of the elements which always has hasLayout=true, including td and body. With body in the list that means that input focus always has a place to go
and also explains why input focus so often ends up on the top of the page.
With td in the list, we can understand why in-page links on table based
sites generally worked from the keyboard.

A Google search for "hasLayout property" will yield a
Microsoft
MSDN page at the top of the list that
describes this property and methods for setting it to true; setting width
and height is just one such method. There are a two of other interesting
articles about the hasLayout property from WebmasterWorld and from satzansatz.de.

With that said, here is the work-around that I use to insure that my in-page links work from the
keyboard with IE6. This is the coding for a typical target.

The styling of the div assigns height and width which turns the hasLayout property to true.
The anchor element (a) is not empty, but contains an invisible gif.
Without that (or some other text content), it turns out
that visual focus doesn't work correctly. I hope that the next version (7.0) of Internet Explorer
will have this fixed. But of course IE6 will be around for a while and
this workaround is not too offensive.

Well, that is what I was using last week, and that is what is used on
several of my pages. But Mike Scott (MSF&W) has written
with a much simpler approach.

Position:absolute has the additional effect of removing
the element from the flow, so it doesn't take up any space. This way we
can use a non-breaking space instead of a 1px image. Since it uses a span,
it can be used inside elements that can't contain divs (paragraphs, headings, etc).
We also don't have to worry about the div causing an extra line break in old/non-css
browsers.

Simplification is certainly welcome. Thanks Mike.

Knowbility (posted August 10, 2005)

Knowbility is an accessibility phenomenon. Under the direction of executive director
and founder, Sharron Rush, Knowbility designed and developed the Accessibility Internet Rally, AIR, which promotes accessibility amongst
web developers and designers and encourages non-profit organizations to use the web.

In preparation for an AIR event, tech teams are recruited and thoroughly trained in web accessibility. They are then
paired with non-profit organizations. Both tech teams and non-profits are local to the area where the Rally is being held.

On Rally Day, each team develops an accessible web site for their non-profit. The sites are judged for accessibility,
usability and aesthetics; the winners are feted at a gala banquet.

Through AIR programs of various types all over the country, hundreds of designers and developers have been trained in
accessibility and have applied that training to many diverse and important web sites - all in a fun-filled and competitive
environment. That remarkable combination makes Knowbility's training the best there is.

Knowbility is expanding it's efforts relating to access to information technology by persons with disabilities by offering
a new Expert Assessment to companies that want to know where they stand on the accessibility curve and what they can do
to get it right.

I have worked with Sharron and Knowbility for several years, especially on AIR programs. It is with a great deal of pleasure
and some humility that I accept the appointment by Knowbility as a Senior Research Fellow. I will oversee the Expert Assessment
program and regularly contribute articles for the Knowbility web site.

Prior to the publication of Constructing Accessible Web Sites, I published an early version of my chapter
on testing tools. The first section of that chapter, Testing Tools,
outlines what can and what cannot be tested relative to the Section 508 Web Accessibility Standards. Although Gez Lemon doesn't phrase
it that way, what he has done is something I wanted to do; he has created a web page that exemplifies violations
of the WCAG checkpoints (instead of Section 508) that will probably not be detected as errors by the testing tools.
That will be a great resource for training in accessibility. We all know it is possible to fool testing tools, and
Gez Lemon's example page provides a wonderful set of examples and a wonderful
teaching tool.

Testing tools are important. The simple fact is that there is a high correlation between errors that can be checked
by software like missing alt text and form controls without labels and those that can't be checked. Perhaps more
important, missing alt text and form controls without labels are very important errors .Testing tools can catch these
errors much better than a human reviewer can and these errors are important. The process at IBM of monitoring
over 13 million pages with automated accessibility checking over the last several years has proved effective in improving
the overall accessibility of the IBM internet and intranet web presence - but the necessity of human review is without
question and will be discussed in a forthcoming article in the IBM Systems Journal, Managing usability for people with disabilities in a large Web presence.

My only criticism of the Gez Lemon article is the suggestion that his results represent the testing tools. In fact
they represent only the free single page accessibility checkers, which he called the "leading accessibility
validators."
You do get what you pay for, and the warnings offered by the real products might have pointed to the possibility
of errors in cases he presents.

Since posting this, Gez has contacted me to say that he has modified his article to say that "the test page
was tested with accessibility validators that are free to use."

The document that breaks the rules is http://juicystudio.com/experiments/invalid.html. It is a great
resource for trainers to emphasize the importance of human review. Stay tuned here for a study of what the real accessibility
validators do with what I consider to be checkable accessibility violations. Of course I consider that a much more
interesting question.

The only myth exploded is Joe Clark.

My new CSS-oriented site (Posted May 1, 2005)

The news is that this is my new site based on Cascading Style Sheets (CSS) instead of tables. It went live around the
first of May, 2005. Many thanks to Liam McGee of Communis, Web Accessibility Consultancy,
for this design. I would be delighted to receive comments on the site or its accessibility.
Please write to me; I would like to hear what you think.

aDesigner from IBM Tokyo Research Laboratory

Chieko Asakawa and the IBM Tokyo Research Laboratory have done it again. The originators of
IBM Home Page Reader have a new web accessibility evaluation tool called
aDesigner which is available from the
IBM AlphaWorks Emerging Technologies site. It's free.

aDesigner is the first new approach to accessibility evaluation that I have seen in a couple of years.
When I experimented with it, I found that the tool picked up errors that others missed and more importantly,
I knew that the errors had been found. I was not inundated with hundreds of warnings and cautions; I could
see the serious issues that were being raised.

There are several neat graphical tricks for visualizing the accessibility of the page.
The length of time it takes to get to portions of the page when listening with a screen reader are
indicated by background shades of blue. When it takes more than 90 seconds (a parameter) the text
is obliterated by the dark blue background. Adding skip links or headings can significantly lighten
up you page. A neat representation of the idea of screen reader navigation.

Skip Navigation and In-page Links

Read about critical problems with skip navigation links using the keyboard with IE6. And there is a work-around for the IE6 bug that is simple and innocuous. The bug and the work-around are general for all in-page or bookmark links.

CSUN 2004 (3/15/04 - 3/20/04)

Another wonderful CSUN conference on Technology for People with Disabilities is now history. If you are interested in accessibility, in technology for people with disabilities, this is the best conference there is. The only problem with CSUN is that there are so many good presentations that you may have to make a difficult choice to attend one and miss the other. And the exhibits are terrific.

In addition to the hands-on pre-conference workshop, I also presented a one-hour session on "Web Accessibility, What Not to Do." The "What not" paper is also available on this site. This is not a technical paper; it is more like comic relief. The paper discusses web sites whose designers had all the right intentions but missed the point. The slides of the "What Not" talk are also available here. The CSUN presentation included two other sites (pages) that are notable for the way they miss the boat - those are described in the slides.

Availability of Constructing Accessible Web Sites

The original publisher of Constructing Accessible Web Sites,
glasshaus of the UK went out of business! The glasshaus (and Wrox) assets have been
acquired by Apress. Apress has republished the book.
As of this writing (August, 2003) both editions of the book, the old one from Glasshaus (ISBN 1904151000) and the
one from APress (ISBN 159009511488), can be found on Amazon. Be sure to order the
new edition, it is $35 and the old edition is $50.

An accessible version of Constructing Accessible Web Sites

If you have purchased Constructing Accessible Web Sites and need an accessible HTML version because of a print disability,
then write to me
and I will see to it that you get the accessible CD of the best book on web accessibility.

Constructing Accessible Web Sites

There is a great book on web accessibility, five stars on
Amazon.com,
Constructing Accessible Web Sites, by Jim Thatcher, Cynthia D. Waddell,
Shawn Lawton Henry, Sarah Swierenga, Mark D. Urban, Michael Burks, Bob Regan and Paul Bohman, published by glasshaus
April, 2002 and republished by Apress, San Francisco, CA, July, 2003. You can
order
the book now from Amazon.com.

My chapters of the book expand on the content of the Web Accessibility course that you will find here, including much more detail on techniques for web accessibility and on the way assistive technology responds to web content both with and without accessible coding techniques.

Other chapters, written by leaders in the field, include the most thorough presentation of accessibility and the
law that I have read (Cynthia Waddell, ICDRI), a study of how web development tools deal
with accessibility including a ranked comparison of the tools (Paul Bohman, WebAIM), and a
chapter on Macromedia Flash (Bob Regan,
Macromedia).
Chapters introducing accessibility (Shawn Lawton Henry, UI Access), on Cascading Style
Sheets (Sarah Swierenga, Usability and Accessibity Center, Michigan State University),
on emerging technologies
(Michael Burkes, ICDRI) and on web accessibility for the enterprise (Mark Urban,
ICDRI) round out the picture.

As one reviewer on Amazon.com put it: "If you're going to buy one book on accessible web sites, this should be at the top of your shopping list."