http://www.w3.org/WAI/PF/Group/track/actions/850

Text is after the table in this section:

http://www.w3.org/WAI/PF/aria-implementation/#mapping_events_visibility

For node changes where the node is not an element or has no accessible object:

    This will likely affect the text output by the IAccessibleText interface. Compute and fire relevant text change events as described above.
    There may be accessible descendants. The appropriate children_changed events MUST be fired for the first-line descendants with accessible objects.

This was poorly written, probably by me :)

> For node changes where the node is not an element or has no accessible object:

A. Some accessible nodes don't have a DOM node, like the accessible node for a list bullet "12. " or the accessible node for :before or :after text.
B. Some DOM node don't have accessible nodes, such as <p>Hello here is some <strong>text</strong> okay</p>. In this case the <strong> doesn't get an accessible object if its own, but is part of the ROLE_PARAGRAPH parent and the strong "text" is just a text range within that. 

In both cases, if anything happens within that content, the "right thing" needs to happen:
1. Text change events on the ancestor which uses the AccessibleText interface
2. Children changed events on any accessible object descendants of that text.

> 
>     This will likely affect the text output by the IAccessibleText interface.
> Compute and fire relevant text change events as described above.
>     There may be accessible descendants. The appropriate children_changed
> events MUST be fired for the first-line descendants with accessible objects.

Is this scenario only relevant to Firefox? If so, then do we really need the text? If not, then do we need to define what happens for the other APIs?

Here's some proposed text that reflects what I understand you to be saying:

"In some cases, node changes may occur where the node is not an element or has no accessible object. For example, a numbered list bullet ("12.") has an accessible node but not a DOM node. Text within a paragraph marked in HTML as <strong> has a DOM node but not an accessible node. It is part of the parent paragraph and the "strong" text is identified as a range within the paragraph text."

I'm lost on the rest of it though. When you say "if anything happens", do you mean "anything" or only the subtree hide/show/add/remove/move scenarios described in the table above the text?

(In reply to comment #4)
> Is this scenario only relevant to Firefox? 
No, it applies to anything that implements AccessibleText from ATK or IA2, which would include WebKit. I don't enough about know how the other APIs deal with text, but there is probably an analagous situation

> If so, then do we really need the
> text? If not, then do we need to define what happens for the other APIs?
I would say we need to define what happens for the other APIs.

> 
> Here's some proposed text that reflects what I understand you to be saying:
> 
> "In some cases, node changes may occur where the node is not an element or has
> no accessible object. For example, a numbered list bullet ("12.") has an
> accessible node but not a DOM node. 
Good.

> Text within a paragraph marked in HTML as
> <strong> has a DOM node but not an accessible node. 
It's actually the <strong> DOM node that has no accessible node. (Background: it's not important enough to get it's own accessible node. The node of accessible objects is kept to the minimum necessary to convey accessibility in order for faster cross-process communication, and text formatting is exposed via text ranges in the AccessibleText interface).


> It is part of the parent
> paragraph and the "strong" text is identified as a range within the paragraph
> text."
> 
> I'm lost on the rest of it though. When you say "if anything happens", do you
> mean "anything" or only the subtree hide/show/add/remove/move scenarios
> described in the table above the text?
Right, only those secnarios. Actually, there are some text removal/change/insertion methods in JavaScript that might also be relevant.

The important distinction here is that the concept of node and element. You can have text node(s) inside an element, but the text nodes are not themselves elements.

Text is always stored in text nodes.

Browsers don't need to necessarily create an accessible object for each node, and can instead expose the text in others ways (e.g. advanced text interfaces).

I think if you read the text in this light it might make sense.

<current>

For node changes where the node is not an element or has no accessible object:

    This will likely affect the text output by the IAccessibleText interface. Compute and fire relevant text change events as described above.
    There may be accessible descendants. The appropriate children_changed events MUST be fired for the first-line descendants with accessible objects.

</current>

<proposed>

In some cases, node changes may occur where the node is not an element or has
no accessible object. For example, a numbered list bullet ("12.") has a
node in the accessibility tree but not in the DOM tree. Text within a paragraph marked in HTML as <strong> has a node in the DOM tree but not in the accessibility tree. It is part of the parent paragraph and the "strong" text is identified as a range within the paragraph text. If any of the changes described in the table above occur on such a node, user agents MUST/SHOULD? compute and fire relevant text change events as described above.

</proposed>

David's comment talks about the difference between elements and nodes. Do we need a definition of "node"?

Need OS X behavior from James

Need to find out what IE and Safari do for text marked as <strong> or <span>. 

Firefox does not create an accessible object for these. It uses IAccessibleText to convey additional information about the text (strong, color, etc.)

Don't necessarily retain DOM structure in the accessibility tree. Common use case is formatting.

The text itself will be in the accessibility tree but the element wrapping it (<strong> or <span>) will not have an element in the accessibility tree.

<change>

Text within a paragraph
marked in HTML as <strong> has a node in the DOM tree but not in the
accessibility tree.

</change>

to

<to>

For text within a paragraph marked in HTML as <strong>, the <strong> element has its own node in the DOM tree but may not have its own element in the accessibility tree.

</to>

Waiting on input from James.

Closed per comments in ACTION-850