Wednesday, September 1, 2010

Firefox 4 beta - AT Vendor Alert

Hello friendly accessibility technology vendors and developers.

As of the Firefox 4 beta 5, the child windows associated with browser tabs have been removed thereby breaking the expectations of most windows screen readers. Regretfully, the timing of this change and the substantial impact it has on AT caught the Mozilla accessibility team by surprise. Unfortunately this change is a critical step in our browser's technical roadmap. The good news is that this issue was quickly discovered during our a recent beta cycle and now we can work together on a fix!

Let's fix this the right way. We probably shouldn't have AT relying on window classes to indicate where browser tabs are, however convenient it might have been years ago. I think, depending on how this per browser tab separation has been used in your code, we can provide an even better solution perhaps even allowing some hack removal on your side. We've very recently been in contact with most of the main AT vendors, and some have what sounds like a fix already in hand. We want to make sure we protect all our users from potential bustage, so we want to hear from all accessibility technology developers that use Windows accessibility API and have been relying on per browser tab window classes.

Something to look for... anywhere you have code checking for a specific window class "MozillaContentWindowClass" your code will almost certainly now be broken for FF4 beta5+. Note this class used to correspond to the HWND of the child content window that received focus whenever the top level window gained focus. To see how things look now I recommend Microsoft's UISpy tool. Be sure to run this against the most recent FF 4 beta or nightly.

We have time but must move swiftly. Please contact us directly or on our accessibility community mailing list.

Thanks for reading.


jamie said...

It's also worth noting that the class name of the top level window (now the only window in most cases) is "MozillaWindowClass", not "MozillaUIWindowClass" as it was previously.

David Bolter said...

@jamie, right, thanks for that addition.

Aaron Leventhal said...

We have a relation from the top level window to the content. I think it's called RELATION_EMBEDS. Anyway, we tried to get AT vendors to move to that method a while back so that the earliest versions of their software would be compatible with the first version that made this change. It's been something like 2-3 years in the planning.

Aaron Leventhal said...

By the way, does this mean that current versions of JAWS and Window-Eyes won't be compatible with Firefox 4?

Will users of those products be required to upgrade if they want to use Firefox 4 with them?

Aaron Leventhal said...

Oh, and one more thing :)

This will probably break other types of software, such as biometric password utilities. I would also ask users to test for compatibility with specialized pointing devices and their scrolling capabilities.

David Bolter said...


Thanks for the info! It seems I can still find surprises in gecko accessibility.

I see our embeds relation only exposing a single child ATM, the currently active content document, which seems okay...

Current versions of AT would break if we fail to mock the old windows structure. We are working on this, but we are advising AT devs to assume we need the long term fix asap.

Some AT actually push updates, and for at least one I think it is just updating a properties file that fixes this. I have a blog brewing about AT upgrade paths. We'll need to solve this and better coordinate release timing as we iterate faster on Firefox down the road.

David Bolter said...

Actually the surprises find me :)

Paddy said...

How to get Sidebar HWND in FF4.0?

I have a addon that have a sidebar created using VC++. For FF4.0 there is only one window(with class name MozillaWindowClass) when checked with Spy++. We do find window to reach the sidebar panel and set that as parent of sidebar pages built in Win32.

I tried getting the sidebar handle. I tried sending sidebar object from JS to CPP. Sidebar object is of type nsIDOMXULElement. I tried getting HWND directly from this, but couldn’t get it. I added one more function that uses nsIAccessibleDocument:: GetWindowHandle method. I converted nsIDOMXULElement to nsIDOMDocument. But when I query to get the nsIAccessibleDocument interface pointer, I don’t get it. It returns NULL.

I also tried getting nsIBaseWindow pointer from nsIDOMXULElement, but that also fails.

I tried sending sidebar window object from JS to CPP and then took the handle of that window.The handle that I get is of browser window. It opened sidebar in whole browser window.

So the problem is how to get the sidebar window object in FF4.0

Norman Robinson said...

This is very important to continued use of Firefox in the U.S. Government: if there isn't accessibility support (specifically relating to Section 508 requirements) then Firefox will be less likely to be used, and in some cases blocked by policy.

David Bolter said...

@Paddy, please post a bug report.

Dev note: using accessibility API for non-accessibility purposes incurs a performance penalty for your users. If possible please seek alternate API for your specific needs.

@Norman Robinson, thanks. We fixed the accessibility issue described in this blog post. Please see my subsequent post for details.