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.

When HTML table is an accesible table

In addition to previous topic Data vs layout tables another aspect of the issue is when layout-guess computation algorithm is applied for HTML table elements.

Shortly the algorithm starts working if HTML table element has associated table accessible. In particular that means it doesn't run if HTML table is not accessible, i.e. it doesn't have any associated accessible object in the accessible objects hierarchy. This happens if HTML table is

• not visible (CSS display:none or visibility:hidden styles are applied)
• not focusable and ARIA role="presentation" is used on it.

Another case is when table element is accessible but it's not a table accessible. From AT perspective the table accessible is an accessible object that exposes a number of table specific interfaces (like IAccessibleTable2 in case of IAccessible2) and has proper accessible roles (like MSAA table or outline roles). So this case is effective (no table accessible is created) when ARIA role used to override native semantics is set on the element, for example role="button". Note, the same time weak ARIA roles like role="banner" don't affect on table semantics and the element gets treated as a table by AT.

In either case HTML table accessibility state affects on its underlying accessible hierarchy. So that if HTML table is not accessible or is not a table accessible then no table structure is exposed, i.e. no rows and no cells.

Also table accessibles may be created for elements different than HTML tables. There are two options to do that:

• CSS display:table
• table specific ARIA roles like role="grid" or role="treegrid".

The layout-guess algorithm returns true in former case and false in second case.

Data vs layout table

Tables in accessible world may be treated as data or layout table. The data tables are supposed to contain data and user should be able to navigate through its structure and get information like headings. Typical example of data table is grid. Layout tables are supposed for elements arrangement on the screen and structure of these tables is likely ignored by AT.

Firefox provides semi-standard layout-guess object attribute on table accessible to say whether this table is for data or layout. Shortly, this attribute is exposed for layout tables only, for data table it's omitted. This object attribute wasn't adopted by IAccessible2 or ATK specifications yet but there is discussion on IAccessible2 list.

Firefox relies on the following algorithm to detect whether the table is layout or not. The algorithm stops when it hits the item. Note, the algorithm is applicable to accessible HTML tables only (check out when HTML table has no accessible).

Algorithm

• Table inside editable area is data table always since the table structure is crucial for table editing
• Table having ARIA table related role is data table (like ARIA grid or treegrid)
• Table having ARIA landmark role is data table
• Table having datatable="0" attribute is layout table (Firefox 10)
• Table created by CSS display style is layout table (Firefox 11)
• Table having summary attribute or legitimate data table structures is data table; these structures are:
• caption element
• col or colgroup elements
• tfoot or thead elements
• th elements 
• header, scrope or abbr attributes on table cell (Firefox 13)
• abbr element as a single child element of table cell (Firefox 13)
• Table having nested table is layout table
• Table having only one row or column is layout table
• Table having many columns (>= 5) is data table
• Table having borders around cells is data table
• Table having differently colored rows is data table
• Table having many rows (>= 20) is data table
• Wide table (more than 95% of the document width) is layout table
• Table having small amount of cells (<= 10) is layout table
• Table containing embed, object, applet of iframe elements (typical advertisements elements) is layout table
• Otherwise it's data table

Updated to Firefox 13.

Accessible document handling in Firefox

The accessible document handling is one of tricky parts of accessible Firefox implementation and implicates not evident details. By providing up-to-dated knowledge about this are I hope this information will be interesting for AT developers.

The document accessible is self-contained unit in Firefox and it's mapped into AT APIs by different ways. For example, neither MSAA nor IAccessible2 has similar concept and accessible roles is a primary test used to detect this particular accessible is document accessible. The same time the knowing that this particular accessible is a document accessible having specific document type might be important for AT because it allows to make assumptions about the content and the ways how it should be expose to the user.

Document types

A document accessible may belong to one or more document types. This is mostly terminological split, however documents may be characterized by specific properties depending on type.

Hierarchical and content-dependent types

Tab document
A document accessible created for web page within the browser tab.

On Windows Gecko provides non-standard way to acquire a tab document accessible from any its child accessible object. For that the following GUID:

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

is used as argument of IServiceProvider::QueryService() method.

Chrome document
A document created for every main Firefox window.

Application document
A document created for any Firefox UI document (also referred as chrome). Note, the application document can be a tab document if it's hosted within a browser tab like add-ons page. In other words, this is either chrome document or tab document.

Dialog document
Different kinds of dialog documents have this type. For example XUL dialog, XUL wizard elements or ARIA dialogs (like role="dialog").

Sub document
A document contained within tab or application document. Sub documents may be nested. For example, documents contained by iframe element accessible objects.

Temporary document
Temporary documents is something we try to avoid but there are few cases when they are created for a short period. The document of this type is replaced by another document shortly.

Native and not native document types

Native document
Native documents are referred to document accessible created for any DOM document. Native document can belong to any of document types listed above.

Not native document
The document accessible can be created when there's no DOM document underneath. It can be done by ARIA like role="dialog" or "document" or "application" placed on HTML element (other than document element or HTML body) or by HTML5 markup like HTML article element. The behavior of such documents may be different from the behavior of native documents since they don't maintain set of features inherent to native documents.

Roles

The document accessible can have one of the following accessible roles:

• DOCUMENT role
• APPLICATION role
• DIALOG role

Exposed role depends on document type. Note that ARIA role can be used to change accessible role.

DOCUMENT role
MSAA / ATK roles: ROLE_SYSTEM_DOCUMENT / ATK_ROLE_DOCUMENT_FRAME.
Primary this role is used for web page documents and for their sub documents.

APPLICATION role
MSAA / ATK roles: ROLE_SYSTEM_APPLICATION / ATK_ROLE_EMBEDDED.
The application role is used for chrome documents when they aren't dialogs. For example, it's used for Firefox UI window, add-ons page or error pages.

DIALOG role
MSAA / ATK roles: ROLE_SYSTEM_DIALOG / ATK_ROLE_DIALOG.
Used for dialog documents.

States

The following states related with document life cycle can be exposed by document accessible.

STALE state
IAccessible2 / ATK states: IA2_STATE_STALE / ATK_STATE_STALE.

The state is exposed when document is not attached to the tree (see Document creation section).

BUSY state

MSAA / ATK states: STATE_SYSTEM_BUSY / ATK_STATE_BUSY.
The state is exposed when document is loading or HTTP request was initiated by user (for example, when clicking on link).

Events

The following events related with document life cycle can be fired.

REORDER event
MSAA event: STATE_SYSTEM_REORDER.
Fired on document container accessible when document accessible is attached to the tree. Target: any document.

LOAD_COMPLETE event
IAcessible2 event / ATK signal: IA2_EVENT_DOCUMENT_LOAD_COMPLETE / "load_complete".
Fired when document is loaded conjointly with its sub documents (the document is referred as completely loaded document). Target: any document, a root of documents loading chain (Firefox 16 and later).

Compatibility.

• [Firefox 15] target: any native document, a root of documents loading chain. 
• [Prior to Firefox 15] target: a tab document.

LOAD_STOPPED event
IAcessible2 event / ATK signal: IA2_EVENT_DOCUMENT_LOAD_STOPPED/ "load_stopped".
Fired when document loading is cancelled. Target: any native document, a root of documents loading chain (Firefox 15 and later).

Compatibility. [Prior to Firefox 15] target: a tab document.

RELOAD event
IAcessible2 event / ATK signal: IA2_EVENT_DOCUMENT_RELOAD / "reload".
Fired when the document is about to reload. 'eventFromUserInput' object attribute on document accessible can be used to detect whether the event was caused by user or programmatically. Target: any native document, a root of documents loading chain (Firefox 15 and later).

Compatibility. [Prior to Firefox 15] target: a tab document. 

STATE_CHANGE event
MSAA event / ATK signal: EVENT_OBJECT_STATECHANGE / "state-change".
Fired when documents is completely loaded or loading was cancelled. Fired immediately after LOAD_COMPLETE or LOAD_STOPPED events. Target: any native document, a root of documents loading chain (Firefox 15 and later).

Compatibility. [Prior to Firefox 15] target: a tab document. 

Document creation

A document accessible is created whenever it gains DOM content or the accessible was requested by AT.

The document has STALE state until its initial content is loaded and until the document is attached to the tree. After that the REORDER event on the document container is emitted. In case of document that is a root in hierarchy the REORDER event is fired on application accessible.

The document keeps BUSY state until it gets completely loaded or loading was cancelled. After that the LOAD_COMPLETE or LOAD_STOPPED events are fired.

Children getting

On Windows the document accessible allows to get any child accessible within it by accessible unique ID (refer to IAccessible::accChild). This is quite useful mechanism to get an event target. Note, this works for ARIA documents as well.

Updated to Firefox 16.

Travel passport online in Russia!

Finally they saved us from standing in long lines and millions of forms fillings when you need to get social services from government. Now you can fill up millions of forms online. Yep, that's great. My travel passport gets expired soon so I decided to obtain a new one online.

I went to gosuslugi.ru where I were asked to sign up. I entered my ID number (well, it's not ID in terms of USA but close at some precision) and they said they will send me activation number by post mail. "Ok" - I thought and after couple weeks I've got a letter with activation number.

Then I activated my account. It was tabbed UI.  First tab "enter ID and activation numbers". Second tab "pick up a password". Third tab: "you see a message that account is activated". So due to some reason they skipped a second tab. They said my account was activated and now I can use it. "Ok" - I thought and tried to use it with empty password. That didn't work. Fortunately, they allowed me to pick up new passport after usual procedure with confirmation by email. "Ok, great" - I thought - "let's move further".

I was ready to fill up the form to request a new travel passport. That was a big form, yep, really big form. I should point who I am, my birthplace, my existing passports, all my jobs and etc, shortly speaking all my biography.

That was a bit unusual UI. I need to choose where I want to pick up the passport when it's ready. You can imagine how Russia is big and how many places to pick up the passport it could have. These options weren't sorted by cities. I listed them one by one looking for a proper one. My wife suggested to start from the end (she had experience to get the travel passport online, well, she didn't get yet) and - oh happiness - my option was in first dozen of options from the end.

I'm not sure why but my browser shows enabled and disabled controls on this web page the same way (I assume that's page styling). The required control elements are marked by red asterisk, this applied to enabled and disabled controls both. Usually when you choose a value in combobox then some controls gets enabled or disabled. So what I did? I clicked any form control to make sure I don't miss anything important.

What UI control would I use if I need to ask a question with answers "yes" or "no". First of all I think of checkboxes. These guys decided to use comboboxes with three options: yes, no and empty (default). I guess they did this because they wanted to make sure the user chooses something and don't skip the question by mistake. Well, this point makes sense but obviously it's not user friendly.

Every region in Russia has a number. So, Irkutsk where I'm located is 38. How many people knows this number and how many people think about the number where they are asked about their region? I'm pretty sure if you have a car then you know the number (because the car number contains a region number). But I'm not sure your answer would be 38 if you were asked about the region you are located. What do I say this for? They have a combobox with options like "38 - Irkutsk region". What do I do when I want to choose my region from list of options? I focus it and start typing "Irk" and etc and expect that I choose the Irkutsk region. Yep, that doesn't happen because they used numbers as prefixes. I run through all options and find a needed one and only then I understand what all these number mean and why I wasn't able to find Irkutsk by typing.

Ok, let's move next. I was asked to point all jobs I had (period, company name, job title, address). They provided a button "add item", by clicking it the new row appears and you can describe next job. They provide neither button "remove item" nor UI to change items order. But I was lucky and typed everything correct.

Finally I reached the form end. I didn't attached my picture yet but clicked on checkbox "Sign the form", I guess that should be similar to the statement "all information I pointed above is true".  But to all appearances it wasn't right guess because I've got an alert message saying that I can sign the form in Internet Explorer browser 6.0 or higher only. I'm Firefox user. I'm Mac user. I don't have IE. I hung for a couple minutes thinking in pretty warm way of site developers. And then I saw the last-hope button "save the form on your computer", I clicked it. The form was cleared and I didn't noticed anything else. Firefox downloads dialog doesn't have anything downloaded. Downloads folder is empty.

I think it's too much for me to repeat these steps today if I find IE 6.0 or higher. I'll fill up the form next time.

Firefox 4 for AT developers

Finally Firefox 4 was released (and finally I finished this post). Marco gave an overview of new accessibility features from user and web developers perspective. I want to tell about technical side, what's new in Firefox 4 for AT developers.

This post doesn't cover all changes introduced in Firefox 4 that may be interesting for AT developers since it's really big area for one blog post. Really, Firefox 4 was developed more than 1.5 year. Near 400 accessibility bugs were fixed. The code is much different than Gecko 1.9.2 (Firefox 3.6) and I don't lie if say more than third of a11y code was changed, redesigned and reworked.

The primary propose of this post is to overview the changes in implementation of ATK and IAccessible2 APIs and highlight important features that come from "under the hood" work.

Performance improvements

Tree traversal.

The accessible tree traversal methods are much faster.

Child by index:

• ATK: atk_object_ref_accessible_child
• MSAA: get_accChild

Children count:

• ATK: atk_object_get_n_accessible_children
• MSAA: get_accChildCount

 Index of the child in parent:

• ATK: atk_object_get_index_in_parent
• IA2: indexInParent

Methods implementation depends on platform and thus the speed of the first call varies. On Windows all necessary data is calculated when accessible tree is created, thus method evaluation is always o(1). On Linux the data is cached on demand in some cases, so when method is called for the first time then it can take o(n). The second time it'll be o(1) too. The difference lies in discrepancy between accessible trees on Windows and Linux.

Relations.

Relation calculation is much faster now. That concerns to relations defined by ARIA and native markups both. There are cases when relations from native markup are more complex than o(1) but no heavy tree traversals anymore.

It's time to start to use IAccessbile2 relation methods over MSAA's accNavigate extension of Firefox if you need multiple relation targets. Of course getting all relations is slower than accNavigate but it shouldn't be a bottleneck.

Group position.

Group position is supplied by:

• ATK: atk_object_get_attributes, 'level', 'posinset', 'setsize' object attributes
• IA2: groupPosition

Group position calculation is smart for most cases. If you request group position for every item in the set then it takes o(n) now, while it took o(n^2) in Firefox 3.6. However there are a few cases where Firefox 4 is not optimal.

Text/Hyperlink/Hypertext interfaces.

Implementation of the following methods shares the same cached data. So the first call of any method calculates the data that is associated with the given hypertext accessible. Performance of the fist call is o(n), where n is a child index pointed by given offset. All subsequent calls deals with the cached data until the accessible tree mutates. When tree was altered then cache is cleared and will be constructed again on demand. Firefox 3.6 performance is o(n) and permanent what may be a bottleneck under certain circumstances, e.g. when AT collect information for every hyperlink.

The following methods take o(1) when data is cached.

Character count:

• ATK: atk_text_get_character_count
• IA2: nCharacters

Hyperlink start and end offsets:

• ATK: atk_hyperlink_get_start_index and atk_hyperlink_get_end_index
• IA2: startIndex and endIndex

Hyperlink count:

• ATK: atk_hypertext_get_n_links 
• IA2: nHyperlinks

 Hyperlink by index:

• ATK: atk_hypertext_get_link
• IA2: hyperlink

The following methods take o(log n) when data is cached.

Text between offsets:

• ATK: atk_text_get_text
• IA2: text

Character at/before/after offset:

• ATK: atk_text_get_text_at_offset, atk_text_get_text_after_offset and atk_text_get_text_before_offset for ATK_TEXT_BOUNDARY_CHAR
• IA2: textAtOffset, textAfterOffset and textBeforeOffset for IA2_TEXT_BOUNDARY_CHAR

Hyperlink at offset:

• ATK: atk_hypertext_get_link_index
• IA2: hyperlinkIndex

Redesigned processing of web pages

Lazy tree construction.

Firefox doesn't update accessible tree immediately when the page mutates, it happens asynchronously always. So JS scripts that mutates the DOM heavily can't block UI.

Correct tree.

Firefox 4 got more powerful logic to create accessible tree so that tree creation is performed in unified way. Most discoverable result of the new logic is:

• CSS generated content is exposed (CSS :before and :after pseudo-elements)
• no DOM text nodes that don't have rendered text are in tree
• nested CSS visibility props are handled correctly (for example, the case when hidden contains visible children)

Tree update.

The accessible tree update process is much more robust. Firefox 3.6 had lot of cases when accessible tree wasn't updated properly and therefore Gecko tried to fix it when related information is requested by AT. Correct fix wasn't always possible and led to broken tree (i.e. parent to child and child to parent navigation wasn't consistent) on a case by case basis.

Mutation events.

Another advantage of new tree update logic is mutation events are fired always and don't get lost because of tree update logic gaps. In the other words AT can trust the mutation events to update their cache:

• MSAA: EVENT_OBJECT_REORDER, EVENT_OBJECT_SHOW and EVENT_OBJECT_HIDE
• ATK: children_chnaged::add and children_changed::remove events.

A note for AT developers on Windows: it's time to consider seriously whether to use show/hide events instead the reorder event. It may be more performant to update accessibles that were added or removed rather than update all child accessibles of the parent the reorder event is delivered for.

Firefox 4 has much smarter event coalescence algorithm that it was, dupe mutation events is not wide case anymore so AT developers can stop the own coalescence and rely on Firefox. It will make AT faster when page is altered in several unrelated places.

Event dispatching.

Firefox 4 practices async event dispatching. The tree can be changed before event is fired. So hide event is delivered for the accessible that is not in tree and text remove events are delivered when text is removed already.

The new design lead to a problem with text removed events on ATK. There are ongoing changes both on Gecko and ATK side. To all appearances the next Firefox and Gnome will get the fix.

Text interface changes

Except the performance improvements introduced in text interface implementation that were said above there are few things worth to mention.

Text attributes.

The text attributes computation algorithm was modified. The range gets splitted by embedded characters, embedded characters are combined into one range. Opposite to Firefox 4 the Firefox 3.6 looks into embedded characters and break a range iff style is changed.

The following example can illustrate new algorithm:

<img>plain<img>plain<img><img><b>bold</b><img><b>bold</b><img>

The text attributes ranges can be presented by notation:

[*)[plain)[*)[plain)[**)[bold)[*)[bold)[*)

* - embedded character, used for image accessible

plain - text without formatting

bold - text with altered text weight

List bullets.

Firefox 4 uses Unicode characters for unordered HTML list bullets depending on bullet type. Firefox 3.6 used the unique '0x2022' character for disc, square and circle list style types.

Polished IAccessibleTable2 implementation

Firefox 3.6 got implementation of IAccessibleTable2 and IAccessibleTableCell interfaces, but not all changes were ready for Firefox 3.6. Firefox 4 gained near complete table support.

Windows hierarchy changes

Shortly the windows hierarchy in Firefox 4 is quite different than in Firefox 3.6. You can read about consequences of this change and approaches how to deal with new hierarchy in David's blog post.

For the reference hierarchies are the following.

The Firefox 3.6 hierarchy:

• MozillaUIWindowClass - main window, contains titlebar
• MozillaWindowClass - Firefox window
• MozillaContentWindowClass - window for tab document

 Firefox 4 hierarchy:

• MozillaWindowClass