Archive for April, 2008

Are Ajax and Accessibility mutually exclusive?

Tuesday, April 29th, 2008

Peter of ATRC and an a11y community member, pointed me to a blog post titled “Stop using Ajax!”, written by OperaDev community member James “Brothercake” Edwards.

My initial reaction was “Oh no! Not another one who uses accessibility as the sole argument to rant against a technology he doesn’t like!”

And while that outraged feeling has diminished somewhat, I still disagree with his article in large chunks. His point, despite the captivating title, is not to stop using Ajax in its entirety, but to stop using it when you don’t need it.

However, this brings up several questions. Whether you need Ajax to accomplish something is a totally subjective issue. I agree that sometimes, it is more worth to use native HTML widgets. But some examples simply horrify me, like a full page refresh when all you want to do is show or hide a quick help text in response to a user entry. Full page refreshes are one of the most terrible things you can do to screen reader users. Today’s screen readers are fully capable of handling dynamic page updates in supported browsers. You usually don’t even lose your virtual cursor reading position when such updates happen. There are obviously desired exceptions to that rule, such as pressing Enter on a link that moves focus to an anchor on the same page. In such cases, the reading position is expected to change.

He also mentions Twitter. I use Twitter myself sometimes, and I find it very handy to find out how many characters I have left when typing a Twitter update. This is one of those examples that could benefit from some ARIA-empowered live region support so Orca and other screen readers could pick it up and speak it automatically.

But first and foremost, we have to face reality: Ajax, although still pretty new, cannot be stopped. Whether we like it or not, it will continue to spread across the web. So his call to stop Ajax when you don’t need it may be several months, if not years, too late.

So what about the accessibility? I agree that some applications are real challenges right now. Google Calendar is one of those, gmail a similar one in some areas. However, Google Maps is not so bad. Since it talks about “maps”, I do not even expect to be able to see the map it brings up. But it is still accessible enough that I can type in my street address, and give the resulting link to someone sighted so they can see where I live.

And there is ARIA. The proposal for Accessible Rich Internet Applications has been evolving for several years now, has been in Firefox 2.0 and is more complete in Firefox 3, and is a way to make all these Ajax apps accessible.
And there are Ajax toolkits out there that already implement ARIA support, making any Ajax application accessible that uses them. One example is the Dojo toolkit, which is being used in the standard AOL freemail frontend, for example. Other toolkits such as Jquery are implementing, or planning to implement, ARIA in the near future, making even more Ajax widgets accessible with browsers and screen readers that support ARIA.

Granted, there is still a big userbase out there who use, or have to use, browsers that don’t support ARIA yet.

But frankly, instead of hiding away in a corner and whining about Ajax being so inaccessible, I prefer going out to web developers, educating them about ARIA and the possibilities it offers, and educate corporate deciders to make the right choices when they decide to implement Ajax. In addition, if I can, I’d like to help other evangelists like Steve Lee who spread the word at a UK Web 2.0 conference recently.

In addition, there are other bloggers like John Resig who are showing how easily it can be implemented, and how a few attributes already can make a major difference.

So, BROTHERCAKE, I invite you to get up to speed on ARIA and what it can do. Get in touch with me or other ARIA developers, learn, and then spread the technology yourself with projects you support. I strongly believe that you’ll be helping the accessibility community much more in that fashion than ranting or giving out hopeless calls like “Stop using Ajax”.

Some better evaluation of image markup

Friday, April 25th, 2008

Thursday’s nightly build of Firefox 3 contained a change that will give more useful information on certain pages where attributes for image tags have been used in some funny way. There are sometimes sites where the web author supplies an alt attribute with an empty string "", and in addition supplies a title with useful data.

As per agreement among ATs and browser vendors, images that have an alt attribute with an empty string should be considered decorative images. However, if a title attribute is specified as well, we now assume that the author means to supply some useful information, and will expose the title as the accessible name for such images.

JAWS and Window-Eyes have applied such magic for quite some time already, and now Firefox supports this method for all who care to use it.

Also, this change restores the fact that, if no alt attribute is specified at all, and no title is present, either, we return a NULL pointer instead of an empty string. This will allow ATs to differenciate between “no alt” and “alt is empty”.

Looking for help with a certain crasher

Friday, April 25th, 2008

I’m looking for someone running Firefox 3.0 Beta 5 who has been submitting crash reports similar to this one.

Basically if you’ve got a crash report pointing to nsAccessNode::ClearCacheEntry, I request that you contact me directly or here on this blog. I’m interested in whether you can reproduce the crash, what steps you’re taking, etc.

Unfortunately, none of the crash reports contain any comments, so we have no clue what’s going on other than that these crashes appear at least once per day.

And while we have fixed the obvious cause, I’m worried that there may be an underlying greater symptom, and it’s my hope that, if the person submitting these crashes can be found, we can determine the actual problem.

Thanks for any assistance!

Started on automated test case development

Wednesday, April 23rd, 2008

As some of you may already have read on the newsgroups, or heard through statements from me or other accessibility developers at the Firefox project, one of my tasks is to develop automated test cases for our accessibility module. I started this project after the all-hands work week end of January. The first tests have been implemented, and pace is picking up speed. So far, I’ve implemented tests for the following interfaces:

  • nsIAccessibleHyperLink, which has to do with all things hyperlink in its various forms.
  • nsIAccessibleHyperText, which is basically text run with hyperlinks in it.
  • nsIAccessibleImage, which was a result of the enhancement to put the SRC attribute in for images. I needed to write a test for that, and morphed it into a general image testing suite instead.

Also, community member Bernd helped a huge amount with writing various tests for the nsIAccessibleTable interface. Alexander Surkov is also contributing test cases for bugs he fixes, and in general we try to provide tests for most of the bugs we fix.

Mozilla uses the Mochikit JavaScript library for most test development. The tests run in what we call the browser chrome, which gives the HTML or XUL pages access to our scriptable interfaces. When tests run, Firefox is in a special mode, not in our day-to-day browsing mode, so there are different security models in place.
Each test consists of two parts: A bigger JavaScript part in the head, and a body consisting of a top part which sets up everything for getting the results later, a reference to the bug number etc. Below that, the actual HTML or XUL starts which puts the pieces to test. For the nsIAccessibleHyperLink chrome tests, i put various links, without and with images, image maps, ARIA links, a named anchor which needs special state flags set to not be recognized as a link accidentally, etc.

In the top part, one or more functions are defined that perform various tests. At the end, one of these functions is set to execute upon page load. That function first gets an accessibleRetrieval object which allows us to get the accessible for any HTML or XUL element. That accessible can then be queried for various properties, or whether it implements, for example, the nsIAccessibleHyperLink interface. Testing for this interface alone is one test that may succeed or fail, so we immediately catch whether something got broken in implementing interfaces, not just in the interface method implementations themselves.

This all works on the platform independent Gecko interfaces, not the platform specific ATK/IA2/Universal Access (once we have that), which allows us to implement one set of tests that runs on all platforms. Implementing platform-specific tests comes later.

In parallel, I’ve started working with colleague Robcee to get the test runs up on a staging server, with the eventual goal of running them on tinderboxes as regular tests along with the other many tests that already contribute in huge parts to the stability and quality of Firefox.

In manual runs of patches against these tests, we’ve already been able to catch a few regressions that would have otherwise been introduced into the product, and been discovered maybe days later. This proves that these tests really help us produce better accessibility code in the future with less chances of regressions.

My current big project is testing the most generic nsIAccessible interface against all kinds of HTML form controls and similar XUL widgets. As you can imagine, there are a lot of ways in HTML to achieve the same result, and each wants to be tested thoroughly. More on this when I get it done.

Update: Henrik pointed out in the below comment that I neglected to post the bug numbers, for those of you who are interested. So here are a few:

Putting final touches on Firefox 3 accessibility

Wednesday, April 23rd, 2008

Over the past weeks the developers and I have been spending time putting the final touches on Firefox 3 accessibility. Here are some of the things worth noting:

  • On Linux, the Library dialog will be working correctly in the upcoming RC1. We had a problem with tree tables changing content which we weren’t handling correctly.
  • In an image accessible’s attributes, we’re exposing the SRC value, starting in today’s nightly. This will allow screen readers to use the ATK/IA2 APIs and not have to rely on the older iSimple* interfaces any longer that previously exposed this information.
  • Also with images, there is a change in the pipeline that will enhance the name finding for an image in the form that, if the author specified an ALT attribute with an empty string as content, but also specified a title, the title is being used even though an alt is present. Screen readers such as JAWS and Window-Eyes apply this magic by themselves right now, and we’re helping out to give the image accessible the proper name in most, if not all, thinkable circumstances.
  • Through triage of sent in crashes from beta 5, we were able to find and fix a couple of crashers that, though rare, could cause some grief on some pages. This again demonstrates that sending in crash reports is very very useful for us, especially since these were all crashes we didn’t catch before. People use software in different ways, and this helps us get prepared for most cases.
  • A few final touches on the ARIA implementation give Firefox 3 a really all-round appearance.

We’ve come a long way since I started to contribute to Firefox 3 accessibility QA as a community member, and I am really happy with the way Firefox 3 is turning out.

Move completed

Tuesday, April 1st, 2008

The move of my blog was finally completed Monday evening CEST.
Everything should continue running smoothly now.

Appologies to the commenter of my “Blog is moving” post: While your comment/warning was very much appreciated, I did not dare to try and migrate the database again to avoid breackage. Therefore, your comment “fell victim” to this move.