The Mozilla Foundation had a booth at CSUN for the fourth year in a row. David, Alexander Surkov and I were present to man the booth, talk to people, and also participate in a couple of general sessions at the conference to gather information and news, and also to network.

Adobe announces broad range support for IAccessible2

One of the biggest news bangs to come out of the conference is Adobe’s announcement to support the IAccessible2 and WAI-ARIA standards in thenext versions of their Flash and Flex products. Both these standards were heavily driven by, among others, Mozilla, IBM and several assistive technology vendors such as NV Access of the NVDA project. Support for the native GNOME and Mac OS X accessibility APIs is also in the works.

In addition, Adobe announced that they will also include IAccessible2 support in their Acrobat and Reader products.

This means that another big player in the software industry is coming forward and supports these widely recognized standards. It is good to see Adobe getting behind the over-all accessibility efforts and helping to drive adoption in this manner!

Three Firebug-related sessions

Hans Hillen of the Paciello Group had two very successful talks about the UI accessibility support in Firebug. The first was a demo of many of the features, using NVDA as the screen reader to demo them. the second was a use-case talk, where Hans explained in some more technical detail how he went about making the Firebug UI accessible to screen reader users.

Both talks were very well received. The first one had quite a broad audience, while the second audience was smaller, but very focused and involved.

In addition, Jon Gunderson of the University of Illinois at Urbana-Champaign held a talk on the Accessibility Testing Extension for Firebug. But unfortunately, due to my travel schedule, I did not have a chance to visit this talk.

It was good to see two Mozilla grantees doing talks at this year’s CSUN, giving visibility to the many facets of Mozilla’s accessibility strategy.

Newer mobile accessibility technologies marching forward

Apple, RIM and Google, the three vendors of mobile devices with well-defined accessibility APIs, all had well-visited talks at CSUN. In addition, I am aware of at least two talks involving the accessible iPhone and iPod Touch 3rd generation that put these technologies to good use to provide a new generation of assistive software, built on mainstream devices.

Well-visited booth

The Mozilla Foundation booth was well visited on all three days that I helped staff it. Comments and questions ranged from the very flattering “I love Firefox and I love what you guys are doing for accessibility!” to “What’s a browser vendor doing at this conference?”. When we then explained why we attended, many of them were keen on trying out Firefox when they got home or back to thheir hotel rooms.

Also, this conference made quite a number of people aware of other Mozilla products than Firefox. While many had heard about Firefox, they had not heard at all about Thunderbird before. But with the better accessibility in Thunderbird, we can now change this and spread Thunderbird in the accessibility community even more!

I personally had a very moving moment on Friday when a deaf/hard of hearing gentelman and his interpreter stepped up to our booth. He was very interested in what we do for accessibility. Before I knew it, I was talking to him through his interpreter, but wasn’t actually noticing it until well into the conversation. At some point, I mentioned Thunderbird, at which point he started joking about the Ford Thunderbird. David, who was present at this conversation, can probably tell a bit more about this, since this was very visual and I only got a third of what he was actually meaning.

David and Alex also took a lot of pictures, which they’ll hopefully upload and share very soon so you all can get a better picture about what CSUN 2010 was like! Mozilla received a big big chunk of good attention, our funding of other accessibility-related open-source projects such as NVDA, Orca and others, definitely is being recognized in the industry as being exemplary. Also, we got a very nice compliment from a gentleman from the Office of homeland security, who told us that he thought our Voluntary Product Accessibility Template is among the best he has encountered so far.

One big failure is there, though

One big problem, which I think should not go unmentioned, is the lack of good internet connectivity in the exhibition hall. For a 2010 information technology conference, having no useable WIFI connection down in the exhibition hall at all is simply unacceptable. The internet connections that were offered were hideously priced, almost like in the mid 1990s when internet connectivity was still not as common as today. Up in the session rooms, the situation was a bit better, at least there were hotspots one could use most of the time.

For next year, one thing I’d like to see is a well thought-through strategy for free wireless internet connectivity throughout all conference locations. A technology conference lives and breathes with the buzz people can create around it by tweeting, uploading pictures etc. People with disabilities are no exception, and instead of roadblocking it, the responsible powers at CSUN should embrace this trend and encourage people to get the word out as easily and hazzle-free as possible!

In summary

I can only say that it was worthwhile going to CSUN yet again, and I am hoping we’ll have a chance to participate next year as well!

Actions for sorting and expansion/collapsing

After some minor setbacks, David’s patch on exposing actions for ARIA sort and expand/collapse attributes finally landed today. This means that:

• An element that has aria-sort set, will expose an action of “sort” to assistive technologies.
• An element that has aria-expanded set to “true” will expose an action of “collapse”, one that has aria-expanded set to “false” will expose an action of “expand”.

These can be used to exactly determine what action will be performed once it is being performed.

Exposure of the HTML5 audio and video element controls

Alexander’s patch to expose the embedded controls of the HTML 5 video and audio elements has landed on mozilla-central. With NVDA, one can now see the grouping where the controls are, and invoke the action on each of the buttons. One can even switch to focus mode on the sliders and use the arrow keys to manipulate them. Note: Due toa different approach in reading our information, JAWS does not yet expose these controls despite this patch. Other screen readers are pending tests.

There are a few problems still which will be addressed soonish: For one, the buttons don’t have text labels yet, and the slider percentage values reflect times rather than actual percentages, so we need to see how we’re going to expose this properly.

In other news

The team, along with a number of community members, has worked on a new high-level accessibility strategy document. Frank Hecker has a blog post explaining this in greater detail.

Spreading the good work of ARIA to mainstream open-source CMS

Peter Krantz, accessibility expert from Sweden, has started an effort to contribute WAI-ARIA landmark roles to mainstream open-source content management systems. If you know one of the CMS that don’t have patches yet, feel free to jump in!

That’s it for this week, see you next week for a new edition!

I’d like to take this opportunity to thank Tim Berners-Lee for writing the initial proposal and sticking to the idea even though his boss, Mike Sendall forgot about it after calling it “vague, but exciting…”.

For me, the web has opened a ton of possibilities that I would have otherwise required sighted assistance with, or which would not be possible for me to do at all, such as casually browsing the New York Times or the Hamburger Abendblatt. I would not be able to look for specific items on, or simply browse the offerings of Amazon. I would not be able to sell no longer needed items on eBay.

Without the web, the world of newspapers would always be more or less hidden from me, unless a sighted person read something to me. The truth is, even though there is very good optical character recognition software out there, newspaper layouts are simply too much to cope, let alone that most newspaper formats don’t fit on off-the-shelf scanners, or even those scanners produced by assistive technology firms.

For shopping, I would always have to rely on someone else to share what they thought the most interesting or compelling offerings in a shopping mall were. It would not be solely my decision what CD I’d buy, what electronic gadget was best for me etc. Oh yes, in many cases I would probably get what I wanted, but it would never be my 100% freedom of choice without depending on others to help me.

And to sell my no longer needed items, I would have to request the assistance of a magazine agent or enlist a sighted friend’s help with preparing an ad, getting it sent in to a magazine publisher, etc.

And these are just some of the things the web has allowed me as a blind person to do independently that were not possible before.

Also, other persons with disabilities benefit hugely from the web, like hearing-impaired who can communicate with anyone without the barrier of most others not speaking sign language. I don’t think it’s exaggerating to say that the web has revolutionized the way persons with disabilities can participate in society.

And that brings me to a point David Baron raised. I can only echo what Wendy Chisholm said in response. I consider access to information just like anyone else to be a right I have as a human being, and the web is the only independent means of doing so. If anyone would try to take that away from me, I promise that I’d prosecute them to the full lawful extent possible.

However, let me emphasize this: I utterly disagree with John Foliot who said that Bespin should never have been released because it uses the Canvas element which is not accessible currently. Here are my reasons for that:

Bespin is not a released product, it’s a Mozilla Labs project that is in a highly experimental stage. Being as open as Mozilla, who share everything we do with the public, some might easily get misled and think that this is a released product already. I can only suggest: Read carefully, then you won’t fall into that trap.

Bespin shows us that the Canvas element can be used for more than just rendering some nice and shiny graphics. It shows that there are still deficiencies in the HTML 5 Canvas element design which need to be rectified as soon as possible. And this is what experiments are for, and always have been: Experiments are there to learn from and improve upon.

The history of the web and the development with the Canvas element we’re seeing now aren’t all that dissimilar in fact. Berners-Lee’s experimental and first theoretical proposal only later turned into something that could actually be useful, when he received his NeXt workstation where he could finally start programming the first web server. He could not have known what would once become the web as we know it today. The inception of the Canvas element probably also happened without realization that someone might actually build a code editor upon it.

In that sense, I am very very thankful for the Bespin team to share their work as early as they did. You guys have shown the web community that there is still work to be done to make Canvas content accessible to screen readers. So rather than whining about Bespin not being accessible, and pushing the developers into the defensive by reflexively yelling before thinking things through, we should get our act together and find out a way to make it accessible soonish! Bespin is a chance, not an evil deliberate move to exclude people with disabilities.

In that spirit, a wholehearted HAPPY BIRTHDAY WORLD WIDE WEB!

Since this is the first issue, and my last update on a concrete new feature/major change has been a while, here’s a broad overview over what we’ve been up to over the past two months or so.

Automated tests on all three active Firefox development branches

Since December 18, 2008, all three Firefox branches that are under development run accessibility mochitests. These branches are:

• Gecko 1.9.0, off which Firefox 3.0.x is being released. These tests actually have been running since roughly the Firefox 3.0.4 timeframe in October.
• Gecko 1.9.1 AKA Firefox 3.1. This is the branch Firefox 3.1 will be released from.
• Mozilla-central. This is the development branch where the next major release after Firefox 3.1 is being developed, with new features going in and more experimental stuff is happening right now.

The most interesting of these is definitely the mozilla-central branch. Both Gecko 1.9.1 and 1.9.0 receive back ports of important features/bug fixes from this branch. The number of tests that run in the accessibility code has surpassed the 2,000 mark two to three weeks ago. We started in December with about 1100 tests.

ARIA 1.0 compliance patches

David has been working on ARIA 1.0 compliance patches and started to put in some good infrastructural stuff as well. Interesting items are:

• The change from aria-grab to aria-grabbed
• The removal of role=”description”
• Some urgently needed fixes for when the document node gets an ARIA role
• Some infrastructural changes and fixes to which ARIA roles can receive what states, and what these states should be

Alex implemented the ARIA spec’s name from subtree calculation algorithm. Of course, despite all the tests, a regression had to creep in, but after that’s fixed, I believe we’re in good shape. The visible result, especially for authors of ARIA-enabled we bapps, is that the Firefox 3.2a1pre nightlies should now always behave according to spec when calculating the name from those elements/widgets that call for its subtree to be aggregated as its name.

As a side note for those interested in the effect our automated tests now have: When Alex tried to land a fix for bug 463645, it clashed with the above mentioned name from subtree bug in an unexpected way, causing an immediate orange flag on the unittest tinderboxen. We’re looking for a solution to that problem right now. Hadn’t we had these tests in place, it would have taken a while for this regression to creep up in manual testing. This way, due to an immediate backout of the offending code, no nightly build ever saw this happen.

New for text attributes

David implemented the conversion to pt algorithm that IAccessible2 calls for on Windows. This change is also in Firefox 3.1.

Alex implemented a faster way of retrieving text attributes,a nd he and I teamed up on better better test coverage for this area.

Accessible relations improvements

Alex worked on better accessible relations support, allowing for a relation to have multiple targets. This will allow assistive technologies to get at aria-labelledby relations correctly. As a sequel, 1:1 relations between tabs and tabpanels were also implemented, allowing ATs to better identify which tab a tab panel belongs to.

Proper reorder events

Alex, our man for big patches , also created a fix for a long-standing bug involving reorder events on DOM mutation changes. Several screen readers need these events to keep track of dynamic changes on web pages to keep their virtual buffers up to date. Some recently inconsistent behavior that often required the user to refresh their virtual buffers manually, should now work much better. This change also is included in the Gecko 1.9.1 branch already, waiting to debut in the upcoming beta 3 of Firefox 3.1.

Thunderbird 3 reading panes

The Thunderbird 3 reading panes received a fix to the way they expose the “from: ” etc. header information. When tabbing through these header fields, one now immediately hears which type of header this is with a compatible screen reader.

This fix was done by Yuen Hoe, a student at the University of Singapore, as part of the NUS Mozilla students project. He picked this bug specifically. Thanks Moofang!

Because this patch relates very closely to SeaMonkey, it was ported there as well, however users can’t take full advantage of this yet in SeaMonkey because of a keyboard navigation issue in the message reading panes.

Better accessibility in SuMo’s live chat

SuMo, Mozilla’s support community, offers a live chat facility that alows users to get help quickly. This live chat was previously not very accessible.

However, Gijs Kruitbosch, the mastermind behind ChatZilla’s accessibility features, worked on a fix, which will see the light in one of the next Sumo updates.

I know this is not strictly the Gecko Accessible module, but nevertheless very important to the over-all Mozilla eco system, and that’s why I’m mentioning it here.

On other fronts

I’m currently working through some of the earliest test files to make them use the common accessibility retrieval and events structures that were implemented more recently. This will help maintainability and make sure that if we add new features to these common functions and classes, every test will benefit from them.

On Windows, all active branches will be more correct in what service IDs they accept when calling the QueryService function. This insures better compatibility with Windows 7, among other things.

Thanks for sticking with me until now! The next reports will be shorter, I promise!

Of course, we welcome your feedback on this kind of post, or on specific areas. So feel free to comment here!

The Mozilla Corporation is looking for a full time engineer to develop accessibility in its software.

The job will involve working with a small team to develop support for a wide variety of 3rd party assistive technologies such as screen readers, screen magnifiers, on-screen keyboards and voice dictation software on a variety of operating systems.

The candidate we are looking for will be an excellent C++ programmer, with experience in COM or XPCOM, as well as working on OS X and either Linux or Windows. Previous experience with the Mozilla codebase is a plus. The candidate should be interested in developing solutions which improve how users with disabilities interact with the web.

Mozilla Firefox already has a strong foundation in this area. However, as the web progresses to provide ever more interactive and complex applications, interesting challenges continue to present themselves. For example, users with significant visual or physical impairments need to be able to interact with applications as complex as online word processors and spreadsheets, as well as content which includes technical information such as diagrams and mathematics. These users will be interacting with the content using text-to-speech, Braille displays, on-screen keyboards, voice input software, and other interesting technologies.

The candidate should be passionate about improving the Mozilla platform and be interested in pushing forward in a truly challenging and interesting area, which improves the lives of users with disabilities by removing barriers to participation on the web.

Some of the standards we will work with include HTML 5, SVG, MathML, WAI-ARIA, OS X’s AXAccessibility API, ATK/AT-SPI and IAccessible2. The team will assist the candidate in becoming more knowledgeable with respect to accessibility topics and the APIs involved.

Occasional travel will be part of the job, such as to disability-related conferences like CSUN and Mozilla project events such as on-sites and summits.

If this sounds interesting to you, get in touch and send in your resume!

Feedback is always welcome, and if you have additional questions that we didn’t cover, but which you think should be answered there, send them in as well!

Obviously, getting these tests running on the production tinderboxes so we immediately see when we broke something is the next step. But until that can be done, we need to find a solution for bug 441974. Basically what is happening is that tests pass when each test file is run stand-alone, but some of these tests fail randomly when running all files in one big batch. But I made some good connections at the Mozilla summit last week, and as soon as we get these passing we’ll start running those tests. They’ll then run along with the many other unit tests we have for Firefox and the Mozilla platform.

I’d like to thank our intern Lukas Blakk and a bunch of other members of the QA and build teams to help me with getting these configs for buildbot right!

This means that assistive technologies now have access to the attributes of any text run on a page via the IAccessibleHyperText::getAttributes or ATK/AT-SPI equivalent API calls.

For example, running today’s nightly build of Firefox 3.1a1pre on Windows, visiting my blog’s main page, bringing up Accessibility Probe, and navigating to the link below the Heading Level 1 that says “Marco’s Accessibility blog”, a call to IAccessibleHyperText::GetAttributes on the link accessible will get you this result:


getAttributes(1) = NULL


Not very fancy, huh?

Tomorrow’s build, however, will yield a completely different result:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:en-US;text-align:center;font-size:40px;background-color:transparent;font-weight:bold;text-indent:0px;color:rgb(255\, 255\, 255);font-family:'Trebuchet MS'\,'Lucida Grande'\,Verdana\,Arial\,Sans-Serif;text-underline-style:underlinesolid;,start=0,end=26]


So, not only do you get information about the font-family, style, color and backgroundcolor, you also get the language this text is in, the underline style, the font-weight etc.

Also when editing, and you misspell something, as soon as you hit spacebar and the red underline appears, the attributes of that word will change and will include “invalid:misspelling;”, indicating that this word is invalid in that it is misspelled. Of course, an according IA2/ATK event will be fired accordingly! Note that the denotation of this may change if the IAccessible2 and ATK groups decide on a different notation for misspellings. Right now, it follows the aria-invalid convention, and we hope that this will be accepted by the groups.

Over the next few weeks, we’ll fine-tune this feature to be a bit more performant and also iron out any last details that might come up.

But if you’re an assistive technology vendor and you’ve been waiting for us to finally expose these text attributes, now is the time to try them out and provide feedback.

Note that Thunderbird and other projects that will be moving to use the Gecko 1.9.1 platform will also get this feature. This means that inline spell checking notification can also be supported for those apps soon!

[Update]: This patch made it into Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071803 Minefield/3.1a1pre just fine. So go take a peek!

• Ability to tag graphics, form fields, links, and other page elements. While some or all of these features have been available in some screen readers already, this feature is unique in that it works across platforms. It also sends the data back to the WebVisum web service so other members of the community can benefit from the labels someone provided.
• Optical Character Recognition (OCR) to try and identify those images that absolutely won’t tell us through their SRC what they’re all about.
• Visual page enhancements such as a high-contrast profile.
• Suppression of automatic page refreshes or Flash content
• And most astonishingly: CAPTCHA solving!

A few days ago, I was approached by the WebVisum development team if I would consider beta testing their extension. So, I had a bit of a head start with this tool, and I was very surprised when I started testing some of the features.

The tests

From my main screen reader, I already knew the capability to label graphics or HTML form elements that have missing alt text or labels. Instead of using those techniques, I applied a few labels to the main navigation images on the CakeWalk homepage using WebVisum. After labelling the graphics from my Windows computer, I fired up my Linux box, installed the extension there and surfed to cakewalk.com. Orca immediately picked up the labels I had given the graphics and used them as the link text.

I then went ahead and labelled the Search combobox on the German Heise Newsticker site. Again, after visiting the page from the other computer, the label for the combobox was read aloud.

And then I actually tried a CAPTCHA. I chose digg.com as my first target since I know they also offer an audio CAPTCHA. Of course this is not a 100% satisfactory solution because deaf-blind people are still left dead in the water with this, but it gave me a good reference to compare the results. I went into the new account creation process on digg, and when it came to the CAPTCHA, I let WebVisum do its magic. Within less than 30 seconds, I got a result back, placed on my clipboard by the extension, ready to paste in. I compared it to what the audio CAPTCHA told me, and the results matched!

I repeated this step two more times because I had first chosen a user name that was already taken, and then goofed up something else in the form, and each time, the result was correct. Totally stunning!

I tried the same on Technorati who also offer an audio CAPTCHA, and got the same results: The CAPTCHA was correctly resolved.

As my third target, I chose MozillaZine, who, despite a couple of attempts on my part, still do not offer an audio CAPTCHA for registration or sending a reply to a forum without being logged in. Without this fall-back mechanism, this is a real-world scenario that visually impaired people are being faced with on an almost daily basis. And I’ll be darned, it worked out! I could register with the MozillaZine forums without any sighted assistance.

The conclusion

There are actually a couple of conclusions, concerns and questions that this extension raises.

The educational aspect

So here we are, having been trying to educate web developers all over the world to use W3C accessibility authoring guidelines, comply with section 508 and what not, and now an accessibility comes along that allows for labelling controls, providing alternative text for graphics, and even share this with the community. So did we do all this educational endeavor invain?

The answer can only be a firm and resolute: “No, we didn’t!” While this extension allows to correct for obvious mistakes like a missing alt attribute on an image, it cannot correct all the requirements there are to meet for section 508 compliance. And it should not! On the contrary: All mistakes one has to correct should be counted against a ranking on a “Wall of shame” kind of statistic that depicts the sites requiring the most corrections. Similarly to the Firefox “Report a broken website feature”, that in Firefox 3.0 also has a “Disability Access” component that allows to report an inaccessible web site, this data should be used to advertise for better accessibility in a future relaunch of that particular site.

Furthermore, there are so many websites that are part of the so-called web 2.0 that are not publically-owned or from a big company, but which are just as compelling to participate. These can usually either not be bothered or cannot financially make it to be 100% sec 508 compliant. Having the possibility to enhance these pages will make the web 2.0 a much more compelling place than it already is in the future.

The CAPTCHA solver

This is probably the most controversial feature. The fact alone that WebVisum is able to solve the CAPTCHAs will probably send shivers up and down the spine of many web developers, website administrators, blog owners etc. that have to fight spam every day. The fact that WebVisum can do it probably means that spambots will sooner or later also be able to do it. Even worse, some could argue that the WebVisum service may be abused by spammers to get CAPTCHA resolution for free.

The WebVisum developers assured me that they’ll make sure that only real people will be able to use their service. Furthermore, the number of CAPTCHAs that can be solved per day per site is limited.

While it is correct to advertise for alternatives to visual CAPTCHAs, the reality is that audio CAPTCHAs, which are the most common alternative, do not allow every person to use them. I already mentioned deaf-blind surfers. But also people who have a hearing impairment and have difficulty deciphering the distorted audio have trouble with this alternative. The CAPTCHA resolution feature allows to solve the problems of these people and also anyone who has trouble reading or hearing the text who is not visually impaired.

Also, this allows access to those private sites and blogs that are under no pressure government- or image-wise to implement an audio CAPTCHA. It definitely lowers the barrier for participation in the web 2.0 world!

Aside from all that, CAPTCHAs only offer a false sense of security. There are much more effective ways of fighting spam than imposing these things upon everybody. My blog, for example, has no CAPTCHA entry for commenting, and still my spam fighting measures have kept this blog clean for as long as it has been in existence. But the sad reality is that CAPTCHAs are an “evil” we currently have to cope with, and WebVisum certainly helps a lot in circumventing these artificial barriers.

My hope is that the WebVisum folks manage to keep their user base spambot-free and that there won’t be any other way to abuse the feature for unsolicited activities.

A few wishes for the future

I see for this extension the potential to become much more than “just” a web helper for the visually impaired. For example, I can imagine this being enhanced to allow hearing-enabled people to provide a textual transcription of an audio clip for deaf surfers, sighted people giving a textual description of not just an image, but a video clip or the like, and other similar cross-impairment possibilities. After all, any hearing-enabled blind could provide such textual transcription of an audio clip for a sighted deaf person.

Aside from this larger-scale vision of mine, a few more basic features such as an undo feature that allows to revoke a server-submitted enhancement will hopefully make its way into near-future versions of the extension.

So: To be able to make up your mind for yourself, go check out the website and extension at www.webvisum.com.

1. Make sure your extension is easily discoverable using the keyboard. A common pattern is to use an icon in the status bar or on a toolbar to launch an extension, but this is not possible to do when using only a keyboard, not a mouse. The easiest and most discoverable way is to add a menu item to the Tools menu to make sure keyboard users can launch it.
2. Labels that are not associated with the control they’re labelling. As a result, screen reader do not know what a particular textbox, menulist, radiogroup etc. is for. Associate your controls with their labels by using the xul:label’s control attribute pointing to the id of the actual control. Works with xul:textbox, xul:menulist, xul:radiogroup and others and is an absolute accessibility must.
3. Xul:page elements that are missing a title attribute. If you use xul:page elements in your chrome, make sure to give them a title attribute that is meaningful. That makes sure screen readers for the blind can properly pick them up and not read the chrome URL instead.
4. Make sure any place holders are in the tab order by using

   <a href="#">

   or

   <div tabindex="0" role="button" onkeypress="if (event.keyCode == event.DOM_VK_ENTER) { ... }"/>

   Any items that are put into a web page to enhance the user experience, and which allow interaction, must be keyboard accessible. A good example is what Adblock plus does with the ability to block certain elements like Flash animations.

5. Make sure all event handlers react to both a mouse and keyboard interaction schema. In fact, you should always completely test your extension without touching the mouse. Some common problems are:
   • For opening context menus, use the oncontextmenu event handler or the context attribute. Do not code context menus to open specifically on the click of the right mouse button, since this will exclude the use of the keyboard. Both oncontextmenu and context will react to the operating system specific context menu triggers.
   • Provide keyboard equivalents for mouse-dependent functionality such as mouseover, mousemove, or ondoubleclick. For example in a listbox where one can double-click a list item to perform a certain action with it, also allow the Enter key or an equivalent keystroke to perform the same action. For Drag And Drop actions, provide context menu alternatives, Copy And Paste, etc.

I hope these are helpful hints for you to make your extension, XULRunner application or the like more accessible to everyone!

For more information, see the XUL Accessibility guidelines on MDC.

Even though I’ve only been with the Mozilla QA team since December 2007, and helped out a s a community member a few months before that, I feel just as excited about this release as those who have been in Firefox development since long before work on Firefox 3 started. This is a great release, with a whole new platform being supported accessibility-wise, a lot of progress having been made on the already supported platform, and a lot of great new features for everyone that make this release a must-have!

For RC1 and the upcoming RC2, I’ve now created testcases for accessibility areas. These tests should be performed using Firefox on either Windows or Linux, and using a screen reader like NVDA, JAWS, or Window-Eyes on Windows, or Orca on Linux. To sighted people not using a screen reader, these expected results do usually not make much sense since they are especially tailored towards output generated by screen readers for the blind.

If you’re interested in helping out testing Firefox on the accessibility side, go get a Litmus account and run the Firefox 3.0 Accessibility test run.

There are a lot of other test runs to perform if you’re interested. You may have to find keyboard equivalents for certain mouse-driven actions, but that should be no problem if you know your Firefox!

Look forward to your results!

To help you out, there are XUL accessibility authoring guidelines available that cover these and other topics extension authors should be aware of. Firefox 3 is much more accessible than previous versions were, also on one additional platform (Linux), so the userbase that may be using your extensions without a mouse and/or with the help of assistive technologies is growing!

Over the past few weeks, I’ve approached a few developers of extensions I use frequently to suggest some accessibility improvements. Here’s a list of extensions who have become more accessible recently:

• Enigmail, an extension for Thunderbird and SeaMonkey that allows you to sign your messages with OpenGPG, has become much more accessible when used with Thunderbird or SeaMonkey Trunk.
• ScribeFire, a blogging extension for Firefox and SeaMonkey, has added a couple of good enhancements recently that make it much more useable with the keyboard. I’ve proposed a few more enhancements, especially missing label/control associations, so upcoming versions will hopefully see more improvements there!
• ChatZilla, an IRC client for Firefox, and part of the SeaMonkey suite, has received a big number of improvements over the past couple of months. I helped test these enhancements and worked with the authors on a couple more keyboard navigation and control labelling issues.

I’d like to thank these extension authors for being so responsive and willing to make their extensions more accessible to a wider audience! I found that often it was only a missing resource like the above mentioned authoring guidelines that can help make an extension more accessible. So, if you are an extension developer, go check them out!

If you have any questions about ways to make your extension more accessible, feel free to contact me either here on my blog, on the #accessibility channel on IRC, or by sending mail to the mozilla.dev.accessibility newsgroup. I’m sure someone from the growing accessibility community or myself will be able to help you out!

Have anything to add? Any success story to share where the accessibility in Mozilla product had an impact on you? Either comment here on the blog, or go to the thread and reply there!

We want to hear from you!

Thanks to the help of Jane, Anne-Julie and Mary, we had good posters, a “fat-head” that immediately caught everyone’s eye, and also lots of goodies to give away to people.

But most importantly, we were there to give out the good word on accessibility work for Firefox 3 and the Mozilla 1.9 platform. I was accompanied by Gijs Kruitbosch, who brought accessibility to ChatZilla, Steve Lee, a Mozilla Foundation grantee and father of the Jambu project, and Ben ‘Cerbera’ Millard, community member, accessibility enthusiast and HTML 5 expert, and currently in the process of writing a proposal for a Mozilla grant.

While day 1 and 3 were rather slow going, with some peaks here and there, but also periods where there were quiet moments, the Thursday was really packed. The question we were asked the most was “What is a browser manufacturer doing at an assistive technology exhibition?” Unlike in the United States, where it is common that big players such as Google, Yahoo, Mozilla or Microsoft show up with booths at such conferences like CSUN, this is not common at all in Germany. So we were the new kid on the block, which brought us some good attraction.

Unlike in the U.S., where we were often asked what Mozilla produces, in Germany many people already know what Mozilla or Firefox are, or are actually using it. I’d say that the figures of market share among the blindness community almost match the figures on the over-all user base. Also, there were many who mentioned that they are using Firefox at their work places.

Those who are using Firefox 2 already were very interested in hearing about the new features in accessibility in Firefox 3. Also high in demand were the fact that Firefox is also accessible on Linux, and the fact that NVDA supports it.

On the more personal side, I had a chance to catch up with a number of people from all around the German-speaking world, some of whom I have known for many years.

Ben is preparing a much more detailled blog post on our SightCity experience. I’ll let you all know when it’s finished! Also, my three sighted friends took lots of pictures. If you guys will let me know where they are, I’ll link them here.

The workshop consisted of four experts, one moderator, and about 20 participants in the audience. In addition to myself, there was one other blind expert, Anna Courtpozanis of WEB for All, one web designer (Martin Kliehm of Namics AG Germany, and Dr. Carlos Velasco of the Fraunhofer Institut für angewandte Informationstechnik, and head of the BIKA Web Compliance Center. The workshop was moderated by Jo Bager, journalist and editor at one of the most widely used German computer technology magazines called C’T.

The workshop started out with the introduction of the experts and their statements for the workshop. Both Dr. Valesco and I put a strong emphasis on ARIA, both getting the point across that ARIA is the way to make Web applications accessible today and in the future.

Mrs. Courtpozanis emphasized that screen reader vendors and browser manufacturers should work more closely to ensure better accessibility for web applications, a point I definitely agree with! She also was of the opinion that accessibility in web applications becoming the common thing rather than the exception, is 10 years away still. I honestly hope that we can reach out to web developers and make this happen sooner!

Mr. Kliehm’s statements were all around sharing innovation and thus infusing progress, that this progress is going to be a community process, and that the W3C will be the over-all infrastructural framework for this progress to happen. As examples, he mentioned Yahoo and Google sharing their applications with everyone, therefore driving the web forward. I also see us at Mozilla in this context: We’re sharing the innovation with everyone, making it accessible and driving adoption through standards workgroups. Needless to say that this is definitely a community process! And yes, the W3C is the organization through which we also drive the standardization effort for ARIA, for example.

After we had finished our statements, the workshop discussion quickly turned into a Q & A session between mostly the web developer audience and the experts. There were many questions regarding interaction with screen readers, quite a number of questions surrounding ARIA (some of the web devs hadn’t even heard about it yet), and the state of support for these new technologies in Firefox and other browsers. We could help the audience understand some of the concepts ARIA is based on. We could also show them how they can use NVDA or Orca to test their sites for accessibility using Firefox 3.

Mrs. Courtpozanis and I also gave examples of web 2.0 applications that we can use, and also those we cannot yet use. One that we both use is GMail, one we both cannot access is Google Docs. Incidentally, the note taking took place in Google Docs on the Eee PC that the moderator had brought along.

In the end, we mutually agreed that the key is to teach and advertise the technologies to make web applications accessible in seminars, at conferences, through blogs and other means to raise the awareness among all web developers, not just those that already are sensitive to accessibility needs.

It was a good workshop, although it did have a Q & A session characteristic over periods of time, seeming more like web devs finally having a chance to ask the screen reader users all the questions they hadn’t had a chance to ask before. But the moderator managed to always keep us in check and not detour too much.

I also visited a second workshop on that day, titled “Accessibility and Mobility”. The goal was to try and see how accessibility on the web 2.0 can also help mobility. The only expert was Mr. Jochen Hahnen, staff member of the competence center Kooperationssysteme des Fraunhofer-Institut für Angewandte Informationstechnik. He brought with him an application consisting of both a web portal and a mobile phone software that allow joggers or bicyclers to record a certain route they regularly take for trasining, and then upload that recording to the portal. That way, they can compare themselves to others using the same track, or see how their fitness develops over time. Incidentally, the web portal and mobile phone software were both not accessible, even though the usefulness for e. g. blind people or wheelchairers is imminently clear: This product could be used to upload good routes to use for wheelchairers, or information like a moving construction work facility for blind walkers. Mr. Hahnen clearly stated that this software is currently designed specifically for sportives, but could be further developed to also be a portal for visually impaired or wheelchair users.

The way this workshop was done leaves me with a bit of a mixed feeling. On the moderator’s side, there was nothing to complain about. He made the best of the situation. However, the expert invited for this workshop, or the product chosen to showcase, was off the mark. It has remained unclear whether the organizers simply didn’t know that the product is currently not accessible, or whether they wanted to give the Fraunhofer Institute an incentive to make it accessible. One thing was clear: Mr. Hahnen could not meet the audience’s expectations, and he was literally pounded on by some participants several times for the application not being accessible.

The over-all framework consisted of both a study conducted by Aktion Mensch on the use of web 2.0 offerings by handicapped people, and the start of the Biene award 2008. The Biene award has been given to German web sites that, in the given year, made a special effort to make their web presence more accessible. It is by now the most recognized award for accessibility in the German-speaking world.

On the inofficial side, I found that many participants already knew one another, and that I was sort of the new kid on the block, only knowing a handful of people from my previous job. In that sense, the conference also had a bit of the atmosphere of a family gathering. And I can say that I was welcomed very warmly into that family. There were several people there who expressed grattitude that Mozilla finally joined them through me.

I’d like to thank the Einfach für Alle team for the invitation! It was an enlightening experience!

The Doc loading stuff

This involved quite a number of complex issues having to do with loading of documents in Firefox, firing the correct events at the correct times, and not firing events when we shouldn’t. For JAWS users on Windows, the mosst visible change of this is that in Thunderbird, every message should now again come up and be read without you having to switch virtual cursor on and off all the time to get messages to read. For Orca users on Linux, Firefox now again fires correct document load finished events and helps Orca to correctly read web sites when it is time to do so.

Focus no longer getting fired on items in non-focused widgets

OK, let’s start with an example: Have you been in the Add-Ons manager in Firefox recently? if so, you’ve probably noticed that, when you switch tabs from Extensions to Themes and back, that when you return to Extensions, your screen reader tells you something about a highlighted Extension. Firefox tricks screen readers into thinking that focus actually shifted. However, focus did not shift, but a focus event was fired when the selection was shown on the list of extensions.
A different example is in Thunderbird, where if you were in Inbox, then went to another folder, then arrowed back up to Inbox, the screen reader would tell you that focus shifted to the message you had last selected in the Inbox folder. Again, focus actually does not shift, but an event is fired for the widget not currently in focus.
Aaron and I put a stop to that happening. As a result, reading should be much more consistent now when you work in both Firefox and Thunderbird. Screen readers should no longer get confused as to where the focus actually is.
By the way: This issue had been around since Firefox and Thunderbird became accessible in their respective 1.5 versions. It was annoying as hell to me, and I am very glad we finally got that one nailed and dealt with!

Tree items updating when they change

When a tree item changes visually on the screen, like a newsgroup or IMAP folder updating its number of total and unread messages in Thunderbird, assistive technologies were until recently not notified of these changes. One had to shift focus away from, and back to the tree view to get the correct picture.
Not any more! Alexander Surkov, one of the great developers working on the accessibility module, has fixed this problem and made sure that ATs can now update when there’s a change.
This again makes working in Thunderbird, but also when you deal with changing bookmarks in Firefox, much more convenient and fluent.

If you haven’t already done so, I would suggest you update to the latest nightlies of both Firefox and Thunderbird on your respective platforms and try out these great improvements!

So what are Places? Well, the satyrical answer to that is: it depends on who you ask. For some, it is a religion. For others, it is a philosophy. For QA people, it can be a curse because if a new Places checkin comes into a nightly build, it might cause regressions.

In all seriousness, though: Places is a technology built into Firefox 3 to store history, bookmarks, downloads and a bunch of other data in an SQLite database. In previous versions, Firefox would store the user’s bookmarks in one format, namely an HTML file, and the browser history in a different format, and these formats weren’t compatible to one another. Moreover, HTML is not a file format you naturally would store data in; It was meant for a different purpose. So this approach had severe limitations in extensibility and flexibility.
The new database-like format, on the other hand, allows for all kinds of interesting features to be implemented. For one, since the data is now stored in a relational database, one can perform database queries on it, allowing for very generic and flexible search and filtering capabilities.

So how does the user benefit from this change? The answer is: In a wide variety of ways.

The new Location bar, AKA the “Awesome Bar”

The first thing anyone who launches Firefox 3 will be presented with, aside from the default start page, is the new Location bar, also known as the “Awesome Bar”. Earlier versions of Firefox allowed you to type in addresses, and depending on whether you had already visited those addresses, would show you suggestions to auto-complete the address you had started typing. This capability is still there, of course, but it has been emensely enhanced. As soon as you start typing, Firefox will search for matches not only within the address (URL) of a page, but also within the titles of pages that it has in its storage. The auto-completion popup will offer items based on the search results, giving both the title and the URL of the found item, and visually highlighting where within the information the text you typed was found. For screen reader users, in each list item, the title will come first, followed by the URL. In addition to that, tags, and keywords for bookmarked pages will be searched. More on tags below.
Along with the title and URL, the search result will have different indicators depending on where the match was found:

• If the page is bookmarked, it is indicated both visually and through accessibility.
• If the match is a tag, it will be indicated.

In other words, once you typed in something you know you have in your bookmarks or browser history somewhere, you can use the auto-complete dropdown to actually find out whether you have the page bookmarked, or whether the term you entered is a tag that can be on multiple bookmarks.

Bookmark tagging

I mentioned tags in the paragraph above a couple of times. Tags are a new feature for Firefox 3 bookmarks. They allow you to categorize your bookmarks, and through the use of the Awesome Bar, retrieve all bookmarks belonging to that category. Some might say “I’ve my bookmarks sorted into folders, what do I need categories or tags for?” Well, I had the same reaction at first. Let me give you an example:

Say you want to collect information about IAccessible2, ATK/AT-SPI, and Universal Access. You have both reference pages for these, as well as links to mailing list archives. You can now sort everything IAccessible2 into one folder, everything AT-SPI into another, and everything Universal Access into a third folder. However, at the same time, you can tag each reference page with a tag of “reference”, and every mailing list archive page with “archive”.
Now, say you want to look for something in the references of AT-SPI and IAccessible2. What you can do now is to type in “reference” (without the quotes) in your new Location bar, and it will show you all bookmarks that have the tag of “reference” on them. You do not have to remember the title, nor do you have to dig through your bookmarks menu to find the bookmark for either IAccessible2 or AT-SPI. How cool is that!

The Library dialog

The Library dialog, which is called Show All Bookmarks on the Bookmarks menu, is where you edit, move and otherwise manage your bookmarks and tags. A very convenient and intuitive dialog which you should feel very familiar with once you get in there.

Adding a bookmark

The way to add a bookmark is to press CTRL+D on the page you want to bookmark. You can immediately press ENTER to save the bookmark, or you can edit tags, or the folder where to store the bookmark. If you press CTRL+D on a page you already bookmarked, you can remove the bookmark.

I hope this lifts some of the mysteries concerning the new Places system in Firefox 3!