Wednesday, February 13, 2013

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.
Argumentsaccessible 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.
Argumentsaccessible of type nsIAccessible
The traversed accessible.
Return valuetrue if the traversed accessible complies with the criteria, otherwise false.

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.

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.

Monday, February 11, 2013

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.