Access Matters

Three articles came to light in “Today’s AJAX and DHTML Best Practices.” Two of the articles went to some length to find ways to move focus as part of an AJAX event. They sought to take the visitor from the trigger event to the results in one smooth, easy move. For those of us who are sighted, we are all familiar with “the yellow fade” that catches our eye and focuses our attention on the element that has changed or is changing. Should we do the same for users of assistive technology? Should we try to get the screen readers to jump to the updated content? Both Gez and James attempted exactly that in their articles, with varying degrees of success. On the other hand, Becky advised against trying to move focus.

Do not automatically shift focus on the page when an update occurs. Changing focus without warning can be distracting for some users, especially if there is no easy mechanism to return to the previous position.

While Becky eludes to another reason in her next paragraph, I’ll be more explicit. What about the people who use screen magnifiers? What if the target area is beyond the field of view of the screen magnifier? The same for people with low vision who have bumped up text size. What are the ramifications of moving the page relatively large increments to expose the new focus? Is this a good user experience?

As an aside, has anyone seen statistics on how many people use magnifiers, compared with other assistive technology?

Do these AJAX situations fit the WCAG 2.0 section 3.2 items?

3.2.1 When any component receives focus, it does not cause a change in context.

3.2.2 Changing the setting of any form control or field does not automatically cause a change of context beyond moving to the next field in the tab order, unless the authored unit contains instructions before the control that describe the behavior.

Then there are the “Rich Internet Applications.” While it is one thing to move focus to a calculator’s results window when the “=” key is pressed, it is quite another when an update to a rich internet application causes multiple simultaneous changes. I reviewed a compensation management application a couple of weeks ago, that I’ll briefly describe with only words. Imagine a department of employees shown in a data table, with one row for each employee and loads of columns with information about each employee. Scroll over to the 7th of 18 columns and give Jane Doe a salary increase. Acting upon the increase causes updates to three cells in Jane’s row and several more in the department summary table at the bottom of the page. Where would you move focus?

Q. So, is it a good idea to move focus or not?

• A Yes, for all but those complex rich internet applications, move focus to the event’s results. Depend on the assistive technology catching up at its own pace.
• B Yes, but… Move focus only when the result is immediately adjacent to the event trigger. This will minimize confusion of shifting the page.
• C No. It’s hopeless.
• D No, isn’t that what “live regions” are all about?

GW Micro has posted a “Public Beta 1” invitation to try out Window Eyes 6.0. They’re offering a cost-free download that will expire at some future date. Some of the features they are highlighting are support for Powerpoint, Outlook calendars, Office 2007, and IE7/Skype. Worth a look, and a test drive.

AJAX has taken off like greased lightning since Jesse James Garrett banged several things together and coined the term. Before that, we were pretty happy with the interactive capabilities of plain ole DHTML. As AJAX has risen, we have also read frequently that it’s not very accessible. We have a few choices: Shrug, don’t worry about it, and let people with disabilities cope with the current state of affairs. Accept the pronouncements that it’s not accessible and go back to our pre-AJAX methods (and let the world pass us by). Or, learn why some AJAX techniques are not accessible how we might make progress. If you’re interested in the third choice, keep reading.

Here we are at the start of a series of AJAX / DHTML best practices. This article builds a sturdy three legged stool which we can stand upon to see farther. Before getting started, I want to set the stage by defining a benchmark. Accessibility’s worst case scenarios are for blind people. The blind are the hardest to accommodate. Some might think that too much attention is paid the blind when there are so many other disabilities, let alone so many more people when the wide range is counted, but the facts are that the others are easier to accommodate. Ensuring good access for the blind is the hardest challenge and therefore the benchmark.

Leg one: Perhaps the single most enlightening current article that helps us understand the difficulties with AJAX is Gez Lemon’s “Making Ajax Work with Screen Readers.” That article is a must read for anyone who is really interested in why all the current fuss about AJAX accessibility. Bottom line, screen readers are not yet capable of reliably recognizing when dynamically updated content has changed. Very often, they will speak the old content instead of the new. Gez helps us understand why, how and when screen readers update their internal buffers, and why our AJAX induced changes might not make it to the listener. Digging into how screen readers work might not be something you ever wanted to do, but the read is well worth it if you want a good foundation for moving forward.

Leg two: Next on our reading list is James Edwards article “AJAX and Screenreaders: When Can it Work?” James, aka Brothercake, has invested a tremendous amount of hard work understanding how JavaScript and screen readers interact. His tests and results are posted right here on this blog. James investigates at a level of detail that would try the patience of most. His SitePoint article explores an how various approaches work and fail (too often) with a dizzying selection of screen readers. Combine Gez’s descriptions of how screen reading modes operate with his findings and with James’ findings, and you will have a deeper appreciation for the challenges of making AJAX and DHTML techniques accessible. By the way, James’ advice to avoid AJAX might be applicable for certain applications. Yet, knowing James, he probably won’t turn away from trying to improve the situation.

Leg three: One of my IBM colleagues, Becky Gibson, is hard at work on a longer term solution (more about that shortly). In the meantime she has published a compilation of general principles we can use now: “AJAX Accessibility Overview.” Becky offers a number of very reasonable ideas which improve the likelihood that the material will be discovered and handled by screen readers. Such as: Place dynamically updated material after the trigger event, later in the reading order. Write new material into an existing div instead of creating a new one. Tell the visitor what to expect, avoid surprises. … and more. The third leg of our sturdy stool and another must read article.

What about that longer term solution? Gez mentioned it in his article. Becky and a good number of other folks are working on it. One one hand, screen readers will slowly catch up with what we implement. On the other hand, work began some time ago under the auspices of the W3C to extend the rather feeble capabilities of existing HTML and XHTML. At the conceptual level, the plan is to use XML and DHTML to expose “roles” and “states” of the elements we use on web pages. Imagine a checkbox being able to report what it is and what state it has to a screen reader, and you’ve got the idea. We will begin to explore more of those ideas in the next article. Until then, there are two more references that you might want to read.

1. Dynamic Accessible Web Content Roadmap
2. Roadmap for Accessible Rich Internet Applications (WAI-ARIA Roadmap)

There’s a stack of ideas that I’m eager to write about. But first, I wanted to put a new skin on the site. This one reflects the wonderful sunny mornings in the woodlands near where I live.

Having too little time to build from scratch, I adopted Mike Cherim’s “Beast-Blog” theme for Wordpress. To Mike’s fine work, which is very accessible, I made a number of visual changes, scrubbed a lot of gunk out of the CSS, and altered the skip links to make them visible.

The design rework is not done, but is ready enough that I can get on to those articles. No excuse for further delay.

Note well: This accessibility statement is a revision of the original from March of 2005. Since then, I improved various features. The more significant accessibility features incude:

• Access keys - I use three simple access keys on this site.
  • Alt + 1 loads the Home page.
  • Alt + 4 positions on the Search input field.
  • Alt + 0 loads this Accessibility Statement.

• Resizable Text - All browsers have the capability of resizing text that is coded in scalable units. All text on this site can be resized as desired.
• Correctly Labeled Forms - Explicit labels for form fields ensure forms are easily understood.
• HTML source order places main content near the top of the file, eliminating the need for skip links.
• Skip link navigation - the very first links on the page offer quick access to main content, sidebar navigation, and this accessibility statement. They are all visible, so as to be helpful to anyone who needs them.
• No pop-up windows are used, except as parts of certain test cases.
• A CSS Signature of “access-matters-com” is included for those who wish to use personal styles. Hint: change all font sizes by changing font-size percentage on the <body> element.

Standards

The site is built to modern web standards and accessibility quidelines.

1. The site uses structured XHTML markup, providing semantic value through the use of headings, paragraphs, lists, and other structural elements.
2. The site validates as XHTML 1.0 Strict.
3. The site conforms with all WCAG version 2.0 checkpoints at the Priority 1 level, and some at the Priority 2 level.

Dennis in Web Axe Episode 24 mentions”

If the tab orders are different than the actual flow of the content on your page, it’s going to be really disorienting for the (screen reader) user.

Really? We know that this sort of disorder will be apparent in regular browsers. That happens with screen readers? Please try a test case where I have intentionally made the tabindex values different that their order in the source. Use your favorite screen reader to tab from link to link and tell us what sequence you hear.