Open Bug 321626 Opened 19 years ago Updated 2 years ago

UAAG: Keyboard users cannot retrieve attribute contents from TABLE & TH

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: mdfft, Unassigned)

References

Details

(Keywords: access) 

From UAAG test suite: Some attributes for the TABLE and TH elements are not implemented.

The specific failing UAAG tests are listed below.  First, here are some recommended solutions:
1. Include a list of tables with CAPTIONS and/or summary attributes in the Page Info dialog and show their CAPTIONS and summary descriptions. 
2. Show TH cell content (or cell content pointed to by a header attribute) as a tooltip when the mouse pointer or the caret moves over a cell in the same column or row as a TH cell. 

Failing UAAG checkpoints related to this bug:

UAAG Checkpoint 2.3 – Render conditional content
- Test  262: SCOPE attribute for TH
  test URL:  http://cita.rehab.uiuc.edu/wai-eval/show-test/index.php?test_id=262

- Test  161: SUMMARY attribute for TABLE elements
  test URL:  http://cita.rehab.uiuc.edu/wai-eval/show-test/index.php?test_id=161

- Test  158: TH elements 
  test URL:  http://cita.rehab.uiuc.edu/wai-eval/show-test/index.php?test_id=158
 Test  161: SUMMARY attribute for TABLE elements
right click on the table open properties and there is the summary.
(In reply to comment #1)
>  Test  161: SUMMARY attribute for TABLE elements
> right click on the table open properties and there is the summary.

OK, but is there a keyboard alternative? Using caret browsing to get to a table with a summary and pressing Shift + F10 displays the context menu, but pressing Shift + F10 when focus is on the Properties menu item does not display the table summary. Screen reader users need a keyboard method.
Blocks: uaag
Keywords: access
Mark, can you come up with a plan for this one? After that assign it to mats.palmgren if there are any core Gecko changes necessary.
Assignee: aaronleventhal → pilgrim
Keywords: sec508
Summary: UAAG: TABLE and TH element attributes not implemented → UAAG: Keyboard users cannot retrieve attribute contents from TABLE & TH
OK, I investigated this for about an hour.  browser.js contains nsContextMenu.prototype.initMenu, which calls this.setTarget(document.popupNode, ...).  When you right-click (with a mouse) on a table border or in any non-link table cell, document.popupNode contains the exact node that you right-clicked on.  If you right-click on a table border, popupNode is the table; if you right-click on a non-link table cell, popupNode is the table cell.  Either way, setTarget properly walks up the DOM hierarchy and eventually finds the table with a summary.  (Search browser.js for "elem instanceof HTMLTableElement && elem.summary" to see this.)

HOWEVER, when you turn on caret browsing, navigate to a cell within the table, and press shift-F10, document.popupNode is *always* the root <html> element.  (This is actually true in the general case too, not just tables.  If you right-click on an H2, document.popupNode.nodeName == "H2", but if you move the caret to be inside the H2 element and press shift-F10, document.popupNode.nodeName == "HTML".)

I tried to walk backwards through the code to find out where document.popupNode is set.  browser/base/content/browser-context.inc creates gContextMenu (an instance of nsContextMenu) with "this" (whatever that is).  http://lxr.mozilla.org/seamonkey/source/content/xul/content/src/nsXULPopupListener.cpp#286 calls SetPopupNode on what appears to be the document (thus document.popupNode).  The comments in the code at that point seem to confirm this.  That code is in nsXULPopupListener::PreLaunchPopup, which is only called by nsXULPopupListener:ContextMenu.

That's where I dead-end.  http://lxr.mozilla.org/seamonkey/ident?i=ContextMenu shows no obvious calling blocks.  My best guess, given my limited knowledge of the Mozilla architecture, is that this is called indirectly somehow.  I can't find the code that actually gets called when you press Shift-F10, so I can't work forwards through the code either.  Hopefully Mats can take it from here.
Assignee: pilgrim → mats.palmgren
In case it wasn't clear from my previous rambling comment, I think that document.popupNode should be the same in both cases, either right-clicking with a mouse or pressing shift-F10 with the keyboard.  If caret browsing is off, I think document.popupNode *is* always the same, but only by accident.  Once caret browsing is on, the "current" node that should be associated with the popup menu (where the caret is) might be some random text node in an element that wouldn't ordinarily get focus, and the keyboard code doesn't handle this case properly.
Assignee: matspal → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.