464211 - Click action on an HTML:table is inconsistently propagated to its descendants

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

Found this on the Jobvite page:
1. Go to http://www.jobvite.com.
2. Click the "Customer login" link.
3. On the following page, try to activate the login text or the two graphics next to it using the Windows screen readers. I get the following results:

1. NVDA: Navigating to either graphic or the "Login" text with the virtual cursor and pressing Enter will activate.
2. JAWS: Moving to either graphic with the virtual cursor and pressing Enter will activate, pressing Enter on the "Login" text will not.
3. Window-Eyes 7.01:Moving to the graphics or text with their browse mode cursor and pressing Enter will not do anything. Neither graphics nor text work.

Comment 1

[Marco Zehe (:MarcoZ)]

Attachment: Testcase based on what's on the Jobvite site.

Looking at the tree for this testcase using AccProbe, I see:

1. A "click" action on the Table accessible.
2. No "Click" actions, but an implemented iAccessibleAction class with "ActionCount", "KeyBinding" and "doAccessibleAction" exposed on the textFrame, and all three TableCell accessibles.
3. A "click" action exposed on the two graphic accessibles in the first and third table cells, and on the "Login" text leaf accessible in the second table cell.

Question: What's the right thing to do? I would submit that, because the graphics are different from a text leaf, JAWS is able to activate these, but not the text. And Window-Eyes probably looks for the click on the parent table cells in all cases, doesn't find it, and barfs. Only NVDA is able to do it right because they probably look at any clickable action exposed and simply do a doAction on the accessible. Doing a doAction on the text leaf accessible using AccProbe properly brings up the onClick handler.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco is this bug still valid?

Comment 3

[Marco Zehe (:MarcoZ)]

Haven't seen any evidence of this being a problem in recent years. Closing as WFM.