Archive for the ‘Orca’ Category

Firefox 3.5.4 fixes certain comboboxes on Linux with Orca

Wednesday, October 28th, 2009

If you haven’t noticed yet, Firefox 3.5.4 hit the web last night. For accessibility, this brings one major fix all of our Linux and Solaris users will appreciate: Certain comboboxes such as the “Security Question” one on the GMail signup page, were broken in the initial releases of 3.5. When you arrowed, Orca would not speak the newly selected item. This was a regression from 3.0 where this worked.

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

Jim Zemlin on this year’s breakout of the Linux desktop

Wednesday, August 27th, 2008

Jim Zemlin of the Linux foundation wrote a very good post on this year being the year of the Linux desktop breakthrough. One thing he did only mention marginally, but which I think is just as important for certain users/markets, is the fact that there is now a wide range of accessibility solutions available for at least the GNOME desktop, which either come directly with the distribution such as the Orca screen reader for the visually impaired, or are easily installable. Screen reading, which includes support for a huge variety of braille displays, magnification, on-screen keyboard solutions, alternative input device support are all available as open-source now and open up the Linux desktop alternative to virtually every potential user.

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.

WordPress 2.6 brings a lot of accessibility improvements!

Wednesday, July 16th, 2008

I just upgraded this blog to WordPress 2.6.

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!

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

Firefox integration into Linux also sounds native to the platform

Thursday, January 10th, 2008

Michael Ventnor, a Mozilla intern working on the Linux integration of Firefox 3, just posted a great summary of the work that has been done for Firefox 3. For those of you who can see, he also has a bunch of screen shots that show Firefox nicely integrating into the Gnome Desktop on Ubuntu.

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.

Orca is gearing up with Firefox!

Friday, December 21st, 2007

Last night, the Orca team announced on their mailinglist that, due to a recent bugfix in the Firefox 3 nightly builds, they were able to drastically improve speed while navigating a web page line by line. I tried it out, and I must say you guys really understated this achievement! It feels like Orca with Firefox is really gearing up now!

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.