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.

Random thoughts

They replaced children's playground by parking lots near of my house. Children don't play soccer, volleyball or tennis anymore. They've got some free time and they can spend it for something else. But don't worry, sooner or later children will grow up and they will buy cars too.

Рядом с моим домом убрали детскую площадку, заменили на автомобильную парковку. Детям негде играть в футбол, волейбол или тенис. У них появилось свободное время, чтобы потратить его на что-нибудь еще. Но не стоит переживать, рано или поздно дети вырастут и у них тоже будут машины.

ARIA autocomples implementation insight

Autocomple widget is a text field having associated list of options so the user is allowed to type value into text field or choose it from available options. Basically autocomplete is variety of combobox control and the user expects it behaving similarly to combobox, for example, keyboard shortcuts should work mostly the same way.

ARIA allows the author to create autocomplete widgets by putting aria-autocomplete attribute on element having role="textbox" or role="combobox" attributes. There are examples on the web, for instance, here or here.

Usually authors prefer to use HTML input control as a base of autocomplete widget because they get typing implementation for free. All they need is to implement autocomplete list, navigation through list options and support standard combobox shortcuts.

When the user navigates autocomplete list then he's able to start typing to adjust list of available options. From implementation point of view the author tends to keep DOM focus on text field. That makes sense because if he keeps it on option element or autocomplete list then he'd need to implement typing on his own. But what is perceived focus in this case? I'd say the focus is on currently traversed option but when the user starts typing then focus goes into text field and visa versa. It's quite similar to comboboxes: when the user navigates options then focus is on option, if the user dismiss popup then focus goes into combobox itself.

How does it look from AT perspective? When the user navigates through options then AT should announce where the user is. For that the author can manage the DOM focus by tabindex technique, use ARIA live regions or try something else. Tabindex technique is really great because it's mapped into accessibility focus concept. The focus concept exists in all AT APIs what makes it universal and all ATs support it very well. Whenever focus is changed it gets announced to the user. ARIA live regions technique is good too because it's supported well by modern ATs.

Reality is the author doesn't want to manage DOM focus because it means special support for typing and he doesn't want to use ARIA live regions because it's hacky, complicated and sort of weird. So we have something else in the end. ARIA provides one more technique called active descendant which is supposed to be mapped to accessible focus but not restricted to it. So this one looks like authors could rely on.

The author wants to keep DOM focus on text field so he sets aria-activedescendant attribute on autocomplete list element which points to currently traversed option. ARIA implementation guide states that aria-activedescendant attribute change results in accessible focus event on pointed descendant iff the container has DOM focus. Since DOM focus is on text field then there's no focus event. Author can't manage aria-activedescendant on text field since autocomplete popup can't be a child of text field due to markup restrictions and strictly speaking it shouldn't be required to be a logical child (aria-owns).  Actually the relation between autocomplete and autocomplete popup should be described by aria-controls attribute but ARIA spec doesn't allow to map aria-activedescendant changes into focus event for elements of this relation.

So what do we have? Some AT APIs (like IAccessible2) has a concept of active descendant and the author could hope that ATs are smart enough so they can pick up active descendant changes and announce them to the user. Reality is active descendant concept is well supported neither by browsers nor by ATs. Some AT APIs (like MSAA) doesn't have it. I'm not aware of other use cases of this concept so that makes me think that active-descendant is going to require special support from ATs. But ATs like focus, they don't want to support new techniques when there's working old one. Autocomple widgets are not special and user interaction can be described in focus terms. That's how Firefox awesome bar works.

What can we do? I think ARIA spec should be changed to extend rules of active-descendant mapping into accessible focus. The following proposition sounds reasonable with me. Allow ARIA menu, listbox and tree widgets controlled (aria-controls) by the widget having DOM focus to manage accessible focus by aria-activedescendant technique. For example:

  <input aria-autocomplete="list" aria-controls="autocomplelist">
  <ul role="listbox" id="autocompletelist" aria-activedescendant="option1">
    <li role="listitem" id="option1">first option</li>
    <li role="listitem" id="option2">second option</li>
  </ul>

In this case AT should report accessible focus on the first option when the text field has DOM focus.