519303 - Same page links to targets with content fires scrolling start accessible event on leaf text node

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20090927 Minefield/3.7a1pre
Build Identifier: 

When a same page link refers to a target which has no content (i.e. an empty tag), activating it causes a scrolling start event to be fired on the accessible for the target (e.g. link or section), as it should. However, when a same page link refers to a target which does have content, the scrolling start event is fired on the text leaf node accessible of the content. For ATs (such as NVDA) which use IA2's IAccessibleText interface and do not use the old text leaf nodes, this is a problem. The scrolling start event should be fired on the deepest accessible which is not a text leaf node.

Reproducible: Always

Steps to Reproduce:
1. Open the attached test case.

2. Activate the "Link to anchor with content" link.
 * Actual: The scrolling start event is fired on the text leaf node of the target content.
 * Expected: The scrolling start event should be fired on the target link accessible.
3. Activate the "Link to div with content" link.
 * Actual: The scrolling start event is fired on the text leaf node of the target content.
 * Expected: The scrolling start event should be fired on the target section accessible.

4. Activate the "Link to anchor with no content" link.
 * Expected and actual: The scrolling start event is fired on the target link accessible.
5. Activate the "Link to div with no content" link.
 * Expected and actual: The scrolling start event is fired on the target section accessible.



This is a partial regression introduced by bug 506389. In the 2009-08-31 build (the build just before the fix for this bug landed), the "Link to anchor with content" link does fire scrolling start on an accessible which is not a text leaf node, though it seems to be the section *after* the anchor, which doesn't make sense to me. However, this is still better for NVDA users than the current situation, as it gets you pretty close to where you want to be. The current behaviour would be better even than the behaviour in <=2009-08-31 if the event could be fired on the accessible above the text leaf node.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

Comment 2

[James Teh [:Jamie]]

Real world test case where this is a problem for NVDA users: http://www.nvda-project.org/wiki/ApplicationSupport
In the 2009-08-31 build, following the links in the table of contents (which link to the section headings) would take you to the paragraph following the heading. Now, because the event is fired on the text leaf node, it has no effect for NVDA.

Comment 3

[Marco Zehe (:MarcoZ)]

This is confirmed.

Comment 4

[alexander :surkov (:asurkov)]

This is probably funny but it is intentional we fire events for leafs. Bug bug 366438 broke this and it seems AT were happy with broken behaviour and even more NVDA started to use this behaviour :) So I think it will be ok to change it as Jamie requested.

Comment 5

[James Teh [:Jamie]]

(In reply to comment #4)
> This is probably funny but it is intentional we fire events for leafs.
We could handle this in NVDA if this is the case (by going parent if it is a leaf node), although it would break on earlier builds of NVDA. However, I thought the idea was to move towards using IAccessibleText as much as possible, in which case the leaf nodes are not used.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)
> (In reply to comment #4)
> However, I
> thought the idea was to move towards using IAccessibleText as much as possible,
> in which case the leaf nodes are not used.

Yes, but this code is pretty old, it was before IA2. I'll get an opinion from other ATs to know what do they think.

Comment 7

[alexander :surkov (:asurkov)]

Everybody is happy with proposed behaviour. However I would like to clear some wild cases:

<a href="#a">link</a>

<p>
  text1
  <a name="a" role="presentation">
  text2
</p>

What target should be in the case of
1) original example
2) no text1 and no text2
3) no text1 and no text2 and no html:p, immediately after html:a is html:body

Comment 8

[James Teh [:Jamie]]

(In reply to comment #7)
>   <a name="a" role="presentation">
Ack. role="presentation" makes this whole thing much nastier. :) I'm not really sure why someone would want to do this, as the whole point of the tag is to act as an anchor target, but as you say, it is certainly possible.

The big problem here is that there is no way for the event to tell us the offset in the IAccessibleText object. This is the one disadvantage of relying on IAccessibleText exclusively; it isn't as accurate unless you have offsets.

> What target should be in the case of
> 1) original example
html:p

> 2) no text1 and no text2
html:p

> 3) no text1 and no text2 and no html:p, immediately after html:a is html:body
Nasty. I guess html:body is the only thing you can do, but that's obviously terribly inaccurate. The only other option would be to resort to the next or previous object; i.e. html:a or whatever was after it.

I'm almost tempted to say the text leaf node should be used if role="presentation" is used. This won't work for NVDA, but it will at least work for other ATs that use ISimpleDOM*.

Comment 9

[alexander :surkov (:asurkov)]

Ok, let's fire it on the first accessible parent if the target is not accessible.

Comment 10

[James Teh [:Jamie]]

This appears to be fixed in 3.7pre. I assume this was fixed by bug 437607 (see bug 437607 comment 15)?

This is not fixed in Firefox 3.6, which makes sense as bug 437607 wasn't landed on 1.9.2. This causes a regression for NVDA <=2009.1users. We can implement a work around, but this doesn't help users of NVDA <=2009.1. Any chance of getting this fix into a 3.6 point release?