380974 - Regression on how JAWS speaks links with other containers inside of them

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Victor Tsaran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070516 Minefield/3.0a5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070516 Minefield/3.0a5pre

It appears that Firefox 3 does not parse HTML in the same way as Firefox 2does, thus presenting incorrect information to the DOM.

Reproducible: Always

Steps to Reproduce:
1. Open both browsers (Firefox 2 and Firefox 3) and keep them on the screen.
2. Open www.yahoo.com in both browsers.
3. Scroll down to the tabs with options such as Mail, Messenger, Radio, Weather, Local and Horoscope.
4. observe results below.
Actual Results:  
Firefox 2:

Mail 1 New Alt+Shift+m
Messenger
Radio

Weather 59°F
Local
Horoscopes

The same bit from Firefox 3:

r/m5 Alt+Shift+m
r/p1
r/uf

forecast/USCA0830_f
r/0z
r/h1



Expected Results:  
Firefox 3 should produce the same output as Firefox 2

This behavior can be easily seen with assistive technology tools, like screen readers, but can also be traced with other debugging tools.

Comment 1

[Jesse Ruderman]

Why do you think this is an HTML parsing bug rather than a bug in the accessibility API code?

Can you make a reduced testcase (a tiny web page that demonstrates the bug / difference)?

Comment 2

[Aaron Leventhal]

Right -- what other debuggign tools? Like DOM Inspector?

Comment 3

[Aaron Leventhal]

I spoke with Victor and this is an a11y hierarchy issue.

Comment 4

[Aaron Leventhal]

Renaming bug to be a little more representative of the problem (I think). Firefox 3 purposely exposes MSAA a little differently now and JAWS may be having some problems with the new structure.

Comment 5

[Aaron Leventhal]

The "r/m5" etc. stuff appears to be part of the link URL's. 

The ROLE_LINK object used to have the ROLE_TEXT object as a direct child. Now there is a descendant in between those two, with the BSTR role "span". Unfortunately that span is missing STATE_LINKED, which might be confusing JAWS.

Comment 6

[Aaron Leventhal]

Attachment: Minimal testcase, an <a> with a <div> inside of it

JAWS is reading the href from the accessible value when it's not a simple anchor with an immediate text child. It should just be getting the accessible name from the ROLE_LINK object.

Comment 7

[Aaron Leventhal]

Rather than making JAWS fix this, I've decided we don't really need any hypertext children of a link. A link should generally just have text and images as children. Once we do that it works with JAWS.

We also don't need to have STATE_FOCUSABLE/FOCUSED on the children of a link unless it's really true. I used to think we need that for Window-Eyes but we don't -- we just need to mimic LINKED/TRAVERSED.

Comment 8

[Aaron Leventhal]

Attachment: Flatten hierarchy inside of anchors, and remove unnecessary state copying code for descendants

Comment 9

[alexander :surkov (:asurkov)]

When you check wheter to create or not hypertext accessible then you check if tagname equals 'a' but you remove focusable/focused states for all accessibles. So should you check rather role than tagname?

Comment 10

[Aaron Leventhal]

You mean because an xlink could create an nsHTMLLinkAccessible?

> you remove focusable/focused states for all accessibles.
We articificially added those to descendents of nsHTMLLinkAccessible. Just removing that code.

Comment 11

[Aaron Leventhal]

Comment on attachment 265204 [details] [diff] [review]
Flatten hierarchy inside of anchors, and remove unnecessary state copying code for descendants

I'm going to remove the r= request until I find out from Freedom Sci if we have to do this.

They should be able to deal with complex links.

Comment 12

[alexander :surkov (:asurkov)]

(In reply to comment #10)
> You mean because an xlink could create an nsHTMLLinkAccessible?

It's one reason. Another one is I do not like when we depend on tagnames. I think it's better to have dependancy on interface or it's a best to depend on ally information (like role in our case).

Comment 13

[Marco Zehe (:MarcoZ)]

I believe we're dealing with this kind of thing in bug 418368 (the nsAccessibleHyperLink interface mochitests). Also, I am not seeing anything wrong with the testcase. Closing as WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008052906 Firefox/3.0. Please reopen if you still see issues.