Archived News Items (2006 and before)

 

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.

WCAG 2.0

Version 2 of the Web Content Accessibility Guidelines are nearing completion. Hundreds of comments have been submitted to the WCAG Working Group which is processing those comments. The Working Group has created a useful Quick Reference document for WCAG 2.0.

Section 508

The Section 508 Accessibility Standards which went into effect in June of 2001 will be revised. A Federal Advisory Committee has been formed to review and update those standards.

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.: C 06-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:

  1. Hide the mouse so you don't mess up this experiment.
  2. Use the TAB key to move to the in-page link that is to be tested.
  3. 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).
  4. 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.

<div style="width:0%;height:0px;">
<a name="maincontent" id="maincontent">
<img src="\images\1-pix.gif" width="0" height="0" alt="" />
</a>
</div>

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.

 

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

<span style="position:absolute;">
<a name="content" id="content">&nbsp;</a>
</span>

Here is Mike's analysis as written in an email to me.

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.

AIR can be a one-day rally or like AIR Interactive during the South By Southwest Festivals, the rally can last several days.

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.

 

An Exploding Myth (Posted August 7, 2005)

Gez Lemon of Juicy Studio has written an article, Testing Invalid Content with Accessibility Validators, about accessibility testing tools and what they can do - well more accurately, what they can't do. Joe Clark characterizes this article as "Exploding the myth of automated accessibility checking" on the Web Accessibility Initiative Interest Group mailing list. The mailing lists I normally watch are buzzing with comments about Joe's assertion and about Gez' article.

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.

The content the new site is pretty much the same as that you have seen recently in the previous format, but that too is going to change. Stay tuned for a new study of accessibility testing tools. Also I will be exploring the relationship between Section 508 and the new Web Content Accessibility Guidelines (WCAG), Version 2.0, from the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). I also plan on updating the Web Accessibility Course in the near future.

 

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.

There are also a number or very good pre-conference sessions. I joined with Jim Allan of the Texas School for the Blind and Visually Impaired, and John Slatin of the Accessibility Institute, the University of Texas at Austin, to give a full day pre-conference hands-on session on Web Accessibility for Section 508. It was a great group of students. The slides for the 508 Web Accessibility course are available here.

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.

Read more about Accessible Web Sites here including sample material.

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

Skip Sidebar.

Popular Pages

: