Firefox 4 beta - AT Vender Relief

Success. Earlier this month I posted an alert about the temporary Windows screen reader bustage with our Firefox 4 betas. Since then Marco posted a status update about our temporary and long term fixes. We worked together, along with the screen reader developers to provide 3 solutions. The first is a temporary hack, and the other two are long term fixes and probably generally useful anyway:

1. The "emulation" hack. For known AT that require them, we resurrected the windows that were recently removed from Firefox. We intend to only create these windows for legacy AT so that users don't necessarily need to pay for upgrades for their software to use Firefox 4.
2. The speedy document accessors fix. We added quick methods to get parent and child documents, and indexed access to documents.
3. The QueryService fix. Provide a special service ID for getting the accessible object that represents the browser tab content document that contains the accessible object queried. Here's some sample code to illustrate how you might use this service:

static const GUID SID_IAccessibleContentDocument = {0xa5d8e1f3,0x3571,0x4d8f,0x95,0x21,0x07,0xed,0x28,0xfb,0x07,0x2e};

// Assuming you have a CComPtr<IAccessible> accessible
CComQIPtr<IServiceProvider> serviceProvider = accessible;
CComPtr<IAccessible> accessibleDoc;
serviceProvider->QueryService(SID_IAccessibleContentDocument, IID_IAccessible, ( void**) &accessibleDoc);

If the 'accessible' is in web content then 'accessibleDoc' represents the main content document that contains 'accessible'. It works in all cases we tested, including special documents like about:addons, as well as documents with iframes where we still always return the main content document. This support is in our nightly builds and will come with FF4 beta7. I hope this will make it easier to manage your cache and context switching.

Thanks for reading.

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.