Frefox merry-go-round

As you know Mozilla switched to fast release cycle this year and no doubts this is a great decision for Firefox users because they don't need to wait couple years anymore before wanted features are added or disturbing bugs are fixed. But everything would be ok if it weren't so bad. There's a downside of this approach. 3d party vendors of products that rely on Firefox this or that way like screen readers aren't always able to pick up new things so fast as they appear. That can happen due to various reasons for example because of different release cycles. That's why users can suffer and blame screen readers. Screen readers blame Firefox and new ways of collaboration must be figured out. One way is to provide up to dated information what's new for assistive technologies (AT) developers in Firefox. I continue Marco's blog tradition where he gives general overview of accessibility improvements and I will highlight the changes that might be interesting for AT developers.

Since many Firefoxes were released after my last post about Firefox 4 for assistive technologies then I list accessibility related changes for both released and upcoming Firefox versions. Note, the post doesn't cover UI changes in Firefox which can be also important for AT developers.

Firefox 5

Firefox 5 appeared shortly after Firefox 4 and actually it was a release we wanted to see as Firefox 4. Firefox 4 was really great, so innovative and so different from Firefox 3.6 but due to tight schedule we were unable to make sure all changes work perfectly. So Firefox 5 is Firefox 4 that contains several crash fixes and few fixed regressions.

Firefox 6

The most interesting thing happened on Linux is plugins accessibility. Thanks to Brad Taylor who contributed this feature the plugins can be made accessible on Linux now. The solution is based on socket mechanism, refer to bug for technical discussion and example. This work might be found remarkable because it could happen that this was a last thing we did for plugin accessibility. It sounds like era of plugins is ending.

ARIA implementation gained support of MSAA accChild method on ARIA documents. So you can get a child belonging to ARIA document by passing unique ID of the child into accChild method called on document accessible. This is quite neat feature for AT developers since they don't need to have special support for ARIA documents.

We've got some ARIA improvements and HTML5 progress element accessibility support. Some crashes and regressions are fixed. Read Marco's blogpost for details.

Firefox 7

Firefox 7 is mostly under the hood work, less memory usage, more performance, more stability.

ARIA role="presentation" if specified on focusable elements doesn't override accessible role coming from native markup. So if the author puts it by accident on focusable HTML table then table accessible is still exposed to AT.

HTML tables got more correct mapping of summary attribute and caption element to accessibility APIs. HTML5 aside element is exposed as complimentary xml-roles object attribute what makes it an equivalent to ARIA role="complimentary" technique.

Thunderbird 7 is a little more accessible now. Orca announces the number of unread messages when inbox is refreshing. Read more in Marco's blog.

Firefox 8

Access keys and keyboard shortcuts are exposed in ATK for any element (previous releases were restricted to menus). I hope Orca users are little happier now.

IAccessibleRelation::get_targets method was regressed. ATs don't rely on this method currently so the regression was noticed too late after Firefox 8 was shipped. The problem is fixed in Firefox 9.

See Marco's post for more details.

Firefox 9

Currently Firefox 9 is in beta stage. Release is expected in December. It doesn't have much new for AT developers and web authors. However it's worth to notice ARIA autocomplete attribute is now respected when used on HTML input element.

Firefox 10

Firefox 10 is in alpha stage now.

Firefox 10 has a great improvement of focus management. If you still stay on Firefox 3.6 due to some reason then it's time to seriously think if it's worth to continue ;)

New focus management makes different widgets of same type to work consistently.

• Listboxes (like HTML select@size>1) claims to be focusable but they never get the focus as long as they have navigable items. Items are focusable and receive focus events.
• Comboboxes (like HTML select) and its options are focusable. Combobox gets the focus until it's expanded, otherwise selected option keeps the focus. If the user navigates items in collapsed combobox then no focus event is fired, items receive selection change events and combobox itself receives value change events.
• Autocompletes like Firefox awesomebar work similar to comboboxes. Except they don't provide a way to navigate options when autocomplete popup is closed.

Also Firefox 10 has changed the support of selection events. Now it fires the following MSAA events for selectable controls:

• EVENT_OBJECT_SELECTION when single item was selected, event is targeted to item.
• EVENT_OBJECT_SELECTIONADD and EVENT_OBJECT_SELECTIONREMOVE when item(s) was unselected and/or items were selected, events are targeted to changed items.
• EVENT_OBJECT_SELECTIONWITHIN when selection within control was changed much, for example, when all items were selected. In this case screen readers can announce that selection was changed rather than announce every changed item. Event target is control.

ATK emits "selection_changed" signal. It doesn't provide information about how selection was changed and it's supposed to be used as generic notification.

caretOffset method of text interface can be used now to change the caret position within a document. That makes this release a little bit closer to virtual cursor implementations based on Gecko's caret navigation mode.

HTML table 'layout-guess' object attribute now takes into account @datatable="0" attribute placed on HTML table. We did that to make the web is a little more accessible. Web authors should use ARIA role="presentation" instead.

HTML map element used as navigation links container is always exposed to AT even if imagemap techniques are used on it. See an example:

  <map id="mapgroup" title="Navigation Bar" name="mapgroup">
    [<a href="#how">Bypass navigation bar</a>]
    [<a href="home.html">Home</a>]
  </map>

Default state on submit button is exposed correctly. So if the form has two submit buttons by accident then only one which is really default exposes this state. HTML options and XUL tree items don't pick up relations from their controls anymore. These are good fixes allowing the screen readers to avoid the confusion.

HTML5 gained complete support of @datalist attribute on HTML input controls which is exposed as SUPPORTS_AUTOCOMPLETION state and supported by IAccessible2 and ATK APIs.