Myth 1 hits the nail on the head. Many people still think you mean "blind users" when you say the word "accessibility".

Myth 1. Accessibility is a single issue

Many accessibility advocates now emphasize focusing on standards-based methods, which include device-independent features that work for a wide range of adaptive and assistive devices. Stick to the standards and design to take best advantage of those d-i features and your site will work with the widest range of devices. Sorting out audiences helps to understand how this approach helps, but the underlying principles are the same. So I am not sure what he means by "We need to think about separate requirements, ... separately."

Of course, AJAX is standards-based, in the sense that JavaScript, XHTML, CSS, and XML all have well defined standards specs. So learn them and stick to them and you have gone a long way toward making your site intelligible to a wide range of devices.

The "design to take advantage of those d-i features" clause above is the critical area. You can make pages that are well-formed, standards compliant XHTML/CSS, yet are full of obstacles for the disabled. An example would be a onclick event - if the only way you can evoke the event is by clicking a mouse, then that event is unavailable to people who cannot use a mouse. So you either have to provide an alternative way to evoke the event, such as having the element accept focus so the reader can just press return to evoke it, or avoid events altogether. The Yahoo Developer Network Design Pattern Library (http://developer.yahoo.net/ypatterns/index.php) includes such accessibility considerations. That level of thinking is what call intentional technology to fulfill design goals.

Complying to standards is also critical to having services work on new devices, like smartphones, cell phones, and mind melds.

Myth 2. All accessibility issues must be fixed

I do think we need to distinguish between which design methods support accessibility and which are leftovers from the days of trying to support pre-standards browsers. Now, the best approach is to design to the standards. The leftovers problem is a bit moot anyway because old browsers are being weeded out by OS and software updates done for security reasons.

One problem here is that a lot of the old accessibility literature that is still on the Web is about minimizing technology to deal with the lack of standards that was the situation in the past. Technologies are a lot more standardized now, so that old literature should be set aside and developers directed to sites that reflect current thinking.

Myth 3. Javascript won't work with screen readers

This one is a bit jumbled. Saying "it doesn't matter how it got there" is misleading. It does matter how the content gets to the displaying software. Adaptive/assistive software definitely likes to have good input - well-formed, standards compliant content structured in logical elements (headings, paragraphs, list items, etc.). Most a/a products make use of attributes such as summary, label, alt, scope, id, and headers to make the content more navigable and intelligible. JAWS, the most common voice browser for the blind, works with IE, as well as with many other Windows programs. IBM Home Page Reader works through IE. Both read off the DOM, which only works as well if the content is well structured to fit into the DOM's tree structure of elements.

I would need to test a/a software that says it can interpret onclick events. What code does is required for that capability to work? The core problem here that onclick requires a mouse, which requires visual abilities. How a blind person, linearly moving through the content, would encounter and recognize that code is the question.

The point about AJAX dynamically updating a page after it has been loaded is a major one for the handicapped. At present, this aspect of AJAX has the potential of cutting the handicapped completely out of using new Web applications. Current adaptive/assistive software generally would not be aware of such changes. Methods are only now being suggested on how pages can be designed to indicate the changes have occured and give a/a software a way to locate and read them. New a/a software may address this puzzle too.

Put on your thinking hats, developers. If you want to do Web 2.0 apps that comply with Section 508 or W3C-WAI, you have to address this problem.

One of the problems in the broad discussion is that Ajax is used to produce interfaces that are richer than simple, readable documents, and screen readers are meant to read. Why are we trying to make rich applications compatible with screen readers? The two seem to have orthogonal concerns. Rich applications offer a delivery interface that have presentation level qualities that are effectively opposite of readable qualities. If a rich web application exposes meta data that follows some standard for expressing rich web application behavior, then we'll be talking about compatible screen readers and not compatibile web applications. There are some forms of content that are simply incompatible with text-to-speech screen readers, so that any discussion of compatibility is worthless. For instance, what is the screen reader compatible form of Beethoven's Fifth? Certain content that is inextricably bound to a medium (such as pure audio) do not have an appropriate equivalent text-based representation. It's not even fantasy - it's just not a meaningful goal. So the requirement of screen reader compatibility for this type of content is misguided. First we have to ask if a particular product meets the basic conditions for compatibility, where it is actually meaningful to attempt compatibility. If the answer is yes, then either the app has to remain stripped down or an alternative interface needs to be built. For two divergent audiences, two appropriately accommodating interfaces are required. There is Gmail with Ajax and Gmail HTML. Rich application compatibility with Screen Readers is even more problematic than historical cross-browser difficulties. At least different browsers have the same basic purpose, which could be considered similar to translating between languages or converting between English and metric units. In some cases, an attempt at compatibility between screen reader interaction and rich app behavior is better likened to alchemy. Sometimes, the conversion can't be done and trying to do so doesn't make sense. With that said, where it can be done and where it does make sense, let's do it. This will require further awareness, standards evolution, and government intervention. Section 508 is under revision to address rich app concerns. There is a reason why current screen readers are crippled with respect to rich apps - the requirements of 508 for web content was published in 2001 and is in desperate need of the update expected in mid 2007.