GW Micro Blog

I recently had a dialog with a developer interested in knowing what kinds of web-based dynamic information we supported. I get this question a lot, and the answer isn't always easy to understand, especially by people who do not use a screen reader on a daily basis. This individual, however, told me that my reply was very helpful, and I'm all about helping people out when I can. With that in mind, here's what I sent her. I hope others find the information useful as well:

The reason that you aren't able to find concrete information about what Window-Eyes (or any other screen reader for that matter) supports in terms of dynamic content is because, as you know, there are a million and one different ways to create dynamic content. Let me give you a couple of specific examples. Most of the time, rather than using existing technologies, companies will develop their own dynamic drop down menu system. Unfortunately, many times, those do not work. And yet, Google and Adobe have two different menu systems that do work. In addition, the Ultimate Drop Down Menu system (www.udm4.com) is a completely accessible version. So when we're asked, "Do you support dynamic menus," we can't just say yes, nor can we say no. It depends on the technology being used.

Another more specific example is creating dynamic elements on a page. Say you're inserting a DIV using JavaScript when a link gets clicked. Most often, screen readers have no idea anything happened, and will not announce the new content. Call the same function a little differently (i.e. HREF="javascript:myfunction();" instead of OnClick="myfunction();") and we are able to refresh our buffer and pick up the new content. So when we're asked, "Do you support dynamic elements," again we can't just say yes or no -- it depends on the technology being used.

The mode that screen readers use to present web based information is static -- it simply takes the text on the page at that time, and speaks it (forms are a bit different because when we interact with them, typically we're no longer in our static "browse" mode, so updated content will usually work fine). Imagine the confusion of trying to read a page that is transforming dynamically if you can't see the screen. Screen readers are very linear -- they read left to right, top to bottom. Sighted people can scan the screen at any point to pick up information.

The bottleneck in understanding accessible content exists because web developers are not screen reader users, and most often do not have the knowledge of how screen readers view web content. Screen reader users are often not web developers, and most often do not have the knowledge of how dynamic content is created.

The solution is what you've already began, and that is to create a dialog with a screen reader manufacturer, providing examples, and working back and forth to come up with something that does what you want and is accessible at the same time. I would also recommend enlisting the help of people who use Window-Eyes on a daily basis to test your content.

AJAX in itself is not inherently inaccessible, any more than, say, C++ is. But you have to know what works and what doesn't. While there are many guidelines for creating accessible applications in C++, AJAX is a relatively new way of doing things, so the guidelines aren't quite there yet. I would recommend you document, and share, what you find works and what doesn't, perhaps through a blog or something so that other developers can learn from your experience.

I'll also add that GW Micro is working closely with Mozilla to support ARIA (Accessible Rich Internet Applications - http://developer.mozilla.org/en/docs/Accessible_DHTML). ARIA is already being adopted by big name companies like IBM and Yahoo. With proper support from the developer community, the question of what works and what doesn't in terms of dynamic content for screen readers will be a question less often asked.