Brand new improvements to Mozilla's Live region support (how they're exposed to ATK/AT-SPI and IA2)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view

Brand new improvements to Mozilla's Live region support (how they're exposed to ATK/AT-SPI and IA2)

Aaron Leventhal-3
We've just checked in important improvements to the way the Mozilla engine
exposes live changes in a document. These improvements will show up in the
August 11 builds (nightly builds, as always are at

End users won't see the difference yet, but the features will help screen reader
developers improve live region support, both for pages that are marked up with
ARIA live region markup, and for pages where the author did not add any
additional markup.

Please read the ARIA spec ( or the live region
report ( to
learn about ARIA live region markup.

As always, we're open to suggestions for changes.

** Summary
1. event-from-input object attribute describes whether user input caused an event
2. container-foo object attributes provide the final live region properties for
a DOM node, if they are provided in the parent chain of elements
3. member-of relationships are used for accessible nodes in atomic region to
point to the top of the atomic region.

** event-from-input
All events will now provide information about whether the event was caused by
user input, or was something that the web page caused.
This information can be retrieved from the object attribute "event-from-input",
which will be set to "true" or "false". If it is not present, then something
went wrong and Mozilla was not able to provide this information. Again, this
will be available for all types of events.

* Focus events, key presses and mouse clicks are counted as user input
* Mouse hovers are not counted as user input
* Page load events are not counted as user input
* Events caused by a timer firing look at what created the timer, and whether
that code was initiated by user input

This information will allow screen readers to improve their heuristics and
performance in terms of deciding what to echo as a web page changes.

** container-foo object attributes
For any mutation event in a page, the author can get the following object
attributes from the event object, if they are defined on some ancestor element
(closest ancestor wins):
* container-relevant: "[additions] [removals] [text]" | "all"
* container-live: "off" | "polite" | "assertive" | "rude"
* container-channel: "main" | "notify"
* container-atomic: "true" | "false"
* container-busy: "true" | "false" | "error"
* event-from-input: "true" | "false" (already described in the previous section,
but re-listed here for completeness)

The "container-" prefix is so named because the attribute describes what the
final computed property of similar name is for that node. This means that the AT
does not need to traverse up the parent chain to get this information.

* For undefined properties, fall back on the default value as defined in the spec
* In ATK/AT-SPI, mutation events consist of text_changed::delete, are
text_changed::insert, children_changed::remove, children_changed::add
* In IAccesible2, mutation events are are IA2_EVENT_TEXT_REMOVED,
CREATE/DESTROY at the request of screen reader vendors, who avoid those events
because they cause crashes on some important system -- SHOW/HIDE are the
equivalent of those events)

** Member-of relation
For regions that are marked as atomic (event node will have
container-atomic=true), additional information is given in the form of the
accessible member-of relation. This will provide a pointer to the accessible
object at the root of the atomic region.

Hope this is helpful, at least to those following the ARIA live region work!
I've also posted this information on the wiki --
dev-accessibility mailing list
[hidden email]
Reply | Threaded
Open this post in threaded view

Re: Brand new improvements to Mozilla's Live region support (how they're exposed to ATK/AT-SPI and IA2)

Aaron Leventhal-3
I've just updated the wiki page quite a bit as well, with the technical details:

dev-accessibility mailing list
[hidden email]