I am looking for an RSS reader for my Mac. Because I’m blind, I have to use VoiceOver to access the screen contents. VoiceOver is a screen reader for the blind. If you have a Mac, press Cmd+F5 and listen to what happens! (That same keystroke turns ift off, BTW.)

If you run Linux and the GNOME desktop, you have the screen reader Orca built-in. If you run Windows, you can get a free and non-intrusive screen reader called NVDA. These can be used to test applications for accessibility. And oh yes, websites, of course, too, if you use a compatible browser for the platform.

Anyway since this was a question specifically directed at Mac OS X users, I got several replies recommending Reeder. I then asked those who had recommended it, if Reeder is compatible with VoiceOver. One of them did a quick test and found out that it isn’t. The feed table doesn’t read, for example, and possibly other stuff that doesn’t work as well.

I just saved €7.99 because I was able to ask the community for help in testing whether an app is compatible with VoiceOver. And unfortunately for the app developer, they just lost a sale because of the fact that their app is not compatible with assistive technologies.

And here’s the message for you app developers out there, web or native: Not being accessible costs you sales! Because not only will people who have to deal with the inaccessibility of applications or web apps not buy your stuff, they will also tell their friends and co-workers about it. And news travels fast around the blindness or other disability-related communities

Likewise, if you make an effort and become accessible, and tell someone about it, good news travels through the relevant communities equally fast! Because we’re not just a bunch of naggers, we are also equally cheerful if we find out, or are told, that there’s more stuff that we can use to broaden our horizons and lower barriers in the world we live in. And this, in turn, will increase sales and is good for business reputation!

There are tons of resources out there on the web, in developer documentation for your platform of choice, how to make your applications more accessible. For web developers, I wrote an article on how to test your web sites for accessibility a good while ago.

And if you’re in doubt, find beta testers, find community members to help out with testing and feedback! I can also be contacted of course, although I cannot provide testing for each platform, but I might also be able to give some general advice.

Happy accessifying!

API support

Most of the changes are under-the-hood changes that do not have API changes as a consequence. There is one new addition that helps get around the now absent window hierarchy, see this post for details and bug numbers if you’re interested.

However, there are a few enhancements that one should be aware of:

Speed

Improving speed was one of the major goals for Firefox 4 in general, and also for the accessibility APIs. A couple of highlights:

• A site like BlindCoolTech, when loaded into the virtual buffer by NVDA, took approximately 6 to 6.5 seconds when loaded with Firefox 3.6.x. With Firefox 4, we’ve managed to cut this time down to under 1 second!
• We also support the very performant Lazy Frame Construction in a very speedy manner so an accessibility-induced lag should hardly be noticeable.
• When calculating meta data for big data tables, we’ve improved the speed by a huge factor. While Firefox 3.6 sometimes would hang for over 5 minutes while calculating data for a 20,000 cell table, this takes only a few seconds now.

New HTML5 elements

We have support in place for the following HTML5 enhancements of Firefox 4:

• The html:output element is supported. We expose it as a text frame, and if it is being controlled by a form or form element, we also properly set the AccessibleRelations. In addition, it receives the implicit attribute. Screen readers will therefore read text inside the output element automagically.
• We have support for the required attribute by setting the ‘required’ accessible state flag on the accessible.
• We’re also working on getting the invalid state supported for the final Firefox 4 release.
• New HTML5 input types like email, number etc. have basic support and are all viewed as text fields currently.

Changes in the WAI-ARIA support

We made changes to the WAI-ARIA support as the spec developed to the new last-call state. We removed features that are no longer supported in the specification. And we made the change that the aria-labelledby attribute now takes precedence over aria-label. When first implemented in Firefox 3.5, and for a long time in the specification, aria-label took precedence over aria-labelledby when used on the same element. Now, this is swapped around. If aria-labelledby is present, aria-label is being ignored.

Bug fixes

Of course, we also fixed a lot of bugs on the way, making the code more stable and secure. Some are part of the performance refactors, some specifically targetted. For example, there are HTML constructs that can cause bad hangs on Linux which we finally nailed down and fixed.

UI and keyboard navigation

There have been several visible UI changes, some of which also have consequences for keyboard users.

Tab strip moved to the top

The tabs moved to the top of the screen, now encompassing the URL bar and search field. Previously, these were not part of the active tab. As a consequence, the tab bar is now reachable by:

1. pressing Ctrl+L to go to the awesome bar
2. pressing Shift+Tab twice to land on the tab bar

So instead of pressing Tab twice when on the awesome bar, now it’s Shift+Tab twice. Other features like accessing the context menu for a tab by pressing Applications remain unchanged.

Pinned tabs

Pinned tabs are tabs that remain visible even when there are so many tabs on the tab bar that it needs to scroll. So your favorite tabs are always visible/accessible. For screen readers, there is currently no distinction between a normal and a pinned tab, but it is exposed nevertheless. And obviously, the context menu item is accessible.

The menu bar is gone, but not quite

The menu bar is no longer visible right away. Instead, a single popup menu, hidden behind the “Firefox” button, is replacing most of the menu bar’s functionality. However, as a keyboard user, you don’t really notice. Press Alt, and the menu bar reappears and you can use it right away again. In fact, I, being blind myself, didn’t even notice that the menu bar was gone because I was simply using the shortcut keys like Alt+F just as I did before. It was not until Surkov asked me whether the Firefox button was accessible that I noticed that there was a UI change.

Note that there is talk of mapping the Alt+F keystroke to specifically open the menu hidden behind the Firefox button in the future. So if Alt+F no longer brings up the “File” menu in the future, this is why.

Add-Ons Manager redesign

The Add-Ons Manager has been redesigned completely. It now also manages Jetpacks, search engines and much more. Moreover, it opens in a new tab instead of a modal dialog. This makes interaction much nicer, one does not have to alt-tab between windows all the time.

There are still some keyboard navigation quirks to be worked out, and some of this may come in an 4.0.x update, but the general functionality is there also for screen reader users.

New UI features that don’t work (yet)

Panorama

The new enhanced tab management feature Panorama, previously known as Tab Candy, is currently not very well navigagble using the keyboard, and hardly exposes any useful information to screen reader users. However, it is going to be possible to make these accessible, we just need a little time to do it. If you’re interested, you can follow the keyboard navigation and assistive technologies support bugs to watch progress.

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!

We initially fixed this for Firefox 3.6 alpha and now also backported the fix to the 3.5 branch.

And there’s more when it comes to the mobile platform. The Mozilla Foundation funded a feasibility study last year to migrate the communication layer for the assistive technology service provider interface (AT-SPI) from using Corba to using DBus, which is a key part in getting screen reading support on the mobile Linux platform. Nokia is now funding the actual migration work. I’ll blog more about the mobile prospective from an accessibility standpoint in the near future.

This version brings with it a number of accessibility enhancements.

One thing you might have noticed already is that there is now a default language set. Default English blogs should now always cause screen readers that support language switching to use the English variant of their default speech synthesizer.

Also new: Whereever possible, there are now labels properly associated with the corresponding form controls. This means that now also screen readers that do not do their own HTML processing should pick up the labels fine.

One more addition that the WordPress team has embraced is the inclusion of some WAI-ARIA markup. Whenever you comment on my blog now, and soon hopefully many others, and you use a compatible browser such as Firefox 3, and a compatible screen reader such as NVDA or Orca, you’ll hear that the text fields also textually marked as “required” in their labels, now are announced as “required” fields. The WordPress default theme now uses aria-required to denote such fields as required, giving even more accessibility to WordPress!

I’d like to thank the WordPress community to embrace ARIA! It is really amazing that ARIA is now finding its way into such a widespread mainstream piece of software!

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”.

I’d like to add a few items that a blind user who uses Firefox 3 with Orca will notice.

Aside from the obvious, the web browsing itself, great attention has been paid to make dialogs such as the Preferences dialog behave like dialogs in other Gnome apps: The Cancel button comes before the OK button while tabbing through the dialog. The dialog itself is found under the Edit menu, as is usual for other Gnome apps, and it’s called “Preferences”, not “Options” like on Windows.

The Location Bar is an AutoComplete, a widget type not found on Windows, but used natively on Linux.

The Places Organizer tree tables are native tree tables, displaying hierarchical information in multi-column view.

As you would expect, the Open File, or any kind of Save As dialogs are the native Gnome dialogs, so if you’re used to using GEdit, OpenOffice etc., you’ll feel right at home, Firefox is not requiring you to learn something new here.

One inconsistency I found–and I’ll have to find out whether a fix for this is planned– is the fact that above mentioned Tree Tables cannot be navigated like, for example, in Nautilus: In Nautilus, you expand a collapsed item using the + key, and collapse it using the - key. Pressing Right Arrow moves you one column to the right, Left Arrow moves you one column to the left. This does not yet work in Firefox (or Thunderbird, for that matter). There, Right Arrow expands, Left Arrow collapses an expandable node, and moving between columns isn’t possible at all currently. So this is typical Windows-style still, but within that, consistent across platforms.

All in all, I expect the browsing experience with Firefox 3 on Linux to be a great one. The Orca team is putting hard work into making Orca work well with Firefox, and the past month alone has brought an emense boost in speed, as discussed here.

A big thanks to both developers of the Mozilla accessibility module and the Orca team for working so closely to make these improvements possible! It shows that the open-source model is one that is really there to benefit all users wherever possible.

If you’re interested in trying out these improvements in responsiveness, get the latest nightly build of Firefox 3, install Py-ATSPI and Orca from source, read the notes on installing and using Firefox 3 with Orca, and have fun with this great improvement!

Note note note: Both Firefox nightlies and Orca installed from source arre products currently under development, so you should use them only for testing, but not expose any valuable data to them without a good backup strategy!

Please see also Orca developer Joanmarie Diggs’s announcement to the Orca list, which tells you all the details of the speed improvement.

By the way: This blog post was created using Firefox nightly of December 20, 2007, and latest Orca trunk from early December 21, which has the speed improvements.