DOM Inspector for accessibility. New features.

A couple new features were introduced after I wrote the previous post about DOM Inspector (aka DOMi). Note, some features aren't available in release version yet. So if you want to get an access to them then you need to build DOMi yourself.

Text attributes

You can inspect text attributes of the accessible object (also refer to IAccessible2 text attributes). All you need is to choose 'Accessible Properties' view in the right panel (make sure 'Show Accessible Nodes' menu option of 'View' menu is on) and then switch to 'Text attributes' tab as it shown below.

You can see default text attributes for the selected accessible and inspect text attributes and offsets for each text range where text attributes stay permanent. For example if you have

  <p><b>hello</b><i>italic</i></p>

then HTML p element is divided into two ranges, the first text range corresponding to 'hello' text has 'font-weight:700' text attribute, the second text range corresponding to 'italic' text exposes 'font-style:italic' text attribute.

Note, if the selected accessible doesn't support nsIAccessibleText interface then 'Accessible Properties' view doesn't have a 'Text attributes' tab.

Note, this feature is not available in current 2.0.13 version.

Search the tree

'Accessible Tree' view of the left panel gained a JS style search. Now when you open 'JS console' (right click on the selected item and choose 'Evaluate JavaScript' menu item) you can operate on JS object named tree having following methods:

search
  Search though the accessible tree and highlights accessibles complying with
    the given criteria.
  Arguments
    accessible of type nsIAccessible
      The root of the subtree the search is performed in.

    criteriaFunc of type Function
      Function invoked for each traversed accessible to determine whether it complies
        with the criteria.
      Arguments
      accessible of type nsIAccessible
        The traversed accessible.
      Return value
        true if the traversed accessible complies with the criteria, otherwise false.

clearSearch
  Clears search results (unhihglights highlighted accessibles)

So say you want to find all text leaf accessibles in the document:

To do that you write the criteria function and invoke the tree.search() on the document accessible.

  function searchTextLeafs(aAcc)
  {
    // Ci is shortcut for Components.interfaces
    // nsIAccessibleRole is an interface defining accessible roles 
    return aAcc.role == Ci.nsIAccessibleRole.ROLE_TEXT_LEAF;
  }

  // 'accessible' is the selected accessible in the left panel, in our case
  // it's the document accessible.
  tree.search(accessible, searchTextLeafs);

When you press 'Evaluate' button then all text leaf accessibles in the document are highlighted.

I should add that all diversity of Gecko accessibility API is available for you from JS console and that allows you to create any criteria you need.

In short, this search tool is rather for JS hackers but it's very flexible and easy enough.

Build DOM Inspector

From time to time I'm getting asked how to build DOM Inspector (aka DOMi) from sources. It's helpful when you need to access to the latest features which aren't available in release yet or if you want to hack on it.

So if you build Firefox on your machine then building the DOMi is easy.

1. You need to download DOM Inspector sources: hg clone http://hg.mozilla.org/dom-inspector/ inspector 
2. Copy the inspector folder under extension folder of Mozilla sources you build Firefox from
3. Add ac_add_options --enable-extensions=default,inspector into your .mozconfig file
4. Build Firefox

That worked fine for a long time. But recently I noticed it doesn't make a trick and DOMi isn't shown in installed add-ons anymore.

In this case cd firefox-objdir/extension; make; helps to appear the DOMi. When you open Firefox for the first time then you will see an extra tab with request to enable the DOMi. You just click the checkbox and restart Firefox.

After that you can summon DOMi from Tools -> Web Developer -> DOM Inspector menu.

Accessible Mozilla: Tech overview of Firefox 20

In short, what's new in upcoming Firefox 20.

You might need to know

During a document loading we may create a temporary document (about:blank) for a short time and then create the requested document. The temporary document is a normal document and behaves as any other document (in particular we fire document load complete event on it). But since it doesn't exist for a long time then it shouldn't get a focus (at least there's no percedence). If the temporary document existence is likely a problem for your application then please contact us.

Apparently this behavior was introduced in Firefox 20, at least that's the first time when we caught it (refer to bug for details).

ARIA

ARIA role combobox exposes an accessible value computed from the content of selected item.

<div role="combobox">

  <div role="textbox"></div>

  <div role="listbox">

    <div role="option">1</div>

    <div role="option" aria-selected="true">2</div>

    <div role="option">3</div>

  </div>

</div>

In this example the accessible value of combobox equals "2". I'm not sure whether this feature has any good effect on ARIA evolution in the web since underlying textbox and listbox are supposed to handle all user input. It was done rather for consistence between HTML and ARIA widgets (see bug).

HTML

We started to build context dependent trees in more cases (refer to bug for details). In particular we don't create list item accessibles for HTML li, dl and etc if they are children of presentational list. For example:

<ul role="presentation">
  <li>item</li>
</ul>

We don't create an accessible for HTML li element in this case.

Also we reject to create HTML table cells if they don't have a table row as a parent. This behavior caused a certain problem. I hope we will be able to backport the fix into Firefox 20.

SVG

We introduced basic SVG accessibility. SVG graphic elements like circle or rect are mapped to accessibility API as graphic role accessibles (see bug). Accessible name and description for these elements are computed from child SVG desc and title elements (see bug for more info).

XUL

We stopped to create accessibles for XUL deck element itself and its child elements if they don't belong to the selected panel. Basically we rolled back to the behavior we had prior Firefox 16. We did that because we were reported that the behavior can be a problem for existing code. In particular, it didn't make a good job for AddBlock+ and JAWS users (see bug).

ISimpleDOMNode

As I wrote before ISimpleDOMNode was implemented as tear off. Let us know if this hits you.

Bug fixes

Windowless/inaccessible plugins don't expose NULL child in MSAA tree anymore (see bug).

Also we fixed an intermittent bug that made us to ignore ARIA role on the body of the document (see bug).

We fixed the case when caret offset was misreported.