Steps to Reproduce: 1. Start Mozilla and GOK. 2. Visit one html page. 3. In GOK, click UI Grab. Bug Observation: Hyperlinks in webpage is not UI Grabble.

Bill, can you give some information on how GOK determine whether a object is UI Grabble? Then we can update mozilla to export LINK in webpage to "UI Grab" of GOK.

The best way to determine the details is to examine the source code of gok/gok-spy.c. As I've said in a previous post, GOK will ignore UI components for which no name or label can be determined, or which do not have the state VISIBLE and SENSITIVE. (The only exception to this is menu items, which need not be VISIBLE). The visibility requirement includes containers, so if a container is not VISIBLE, its children will not be searched by GOK. Using gnome-help (which displays hypertext) with at-poke should help you see the details of a working example for which GOK successfully does UI Grab and activation of hyperlinks. at-poke (GNOME cvs module at-poke) is a utility which can display details about a program's accessibility hierarchy, so it can be very useful for these sorts of investigations. Note that once a hyperlink is "UI Grabbed", GOK tries several different strategies for activating it, so there is more than one way to implement AtkAction on the hyperlink itself, which is compatible with GOK. Ideally, the first AtkObject returned by AtkHyperlink_getObject() should implement AtkAction, and the first AtkAction should activate (open) the link; however it is also possible to implement AtkAction on the AtkHyperlink object itself. The first method is preferred, but the second method is used by gtkhtml2 and gnome-help.

Bill, thanks for your information. The reason why GOK can't expose link in html is that "HTML_CONTAINER" exports AccessibleText Interface, which make GOK stop at this level and won't go deep into the content of HTML_CONTAINER. Actually, "HTML_CONTAINER" shouldn't export AccessibleText interface. This patch deals with this issue. In additional, the name of link isn't exposed, which is bug 241062. (Mark 241062 blocks this one.)

Louie: can you point me to a built binary, or a jhbuild script which will build the appropriately configure mozilla?

(In reply to comment #4) > Louie: can you point me to a built binary, or a jhbuild script which will build > the appropriately configure mozilla? Bill, you can download Moz 1.7 at http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7/mozilla-i686-pc-linux-gnu-1.7-installer.tar.gz, or the nightly build at http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/, both of which can reproduce this bug. AFAIK, Mozilla has jhbuild script. Building mozilla is quite straightforward. After pull the source code, do the following: 1. copy the attached mozconfig file to the build workspace 2. configure; make Accessibility feature will be enabled by default.

sorry for the typo: Mozilla has jhbuild script -> Mozilla has no jhbuild script.

Louie: Mozilla *does* have a jhbuild script: see http://cvs.gnome.org/viewcvs/jhbuild/jhbuild/modtypes/mozillamodule.py?rev=1.4&view=log I normally use jhbuild for building mozilla, but it's not clear that the existing jhbuild mozilla setup enables accessibility. I'll try a rebuild and see if it works OK.

Louie: Can you please update the status on this bug? Do we still need this patch in the trunk?

updated patch.

In the updated patch, 3 changes has been made: 1. Get rid of nsIAccessible(Editable)Text interface for HTML_CONTAINER because it prevents mozilla from exposing inner elements to GOK. 2. Get rid of nsIAccessibleTable interface from HTML table because A) it prevents mozilla from exposing inner elements to GOK; B) The concept and function of HTML table and nsIAccessibleTable are different. (please refer to the comment in code) 3. Bug fix for nsHTMLLinkAccessibleWrap: ensure to initialize private members before using functions.

Comment on attachment 168182 [details] [diff] [review] patch_updated >+ if (accRole == nsIAccessible::ROLE_TREE_TABLE) { >+ // In most cases, html table is used as container to arrange the webpage, >+ // not to represent a "real" table with practical colum, colum heaer, row. "practical column", "column header"

Comments from Bill: I actually don't agree with the assessment that HTML tables should not implement AtkTable. It was the intention of AtkTable that HTML tables *would* implement that interface. Please don't remove this support! If there are issues with GOK then we will find another way to work around them. AtkTable is important!

Bill, HTML table is a little different from XUL table because they are not alway "visible". For example, in http://www.sun.com , all the content is arranged in a quite complex table (and table in table, ......). If enabling AtkTable interface for HTML table, the visible elements (e.g. link, button, html inputbox, ...)won't be exposed directly in GOK. Users can only see lots of table in GOK UI-Grab and it's annoying to find "visible" elements under several level tables in GOK. For screen reader, many html text will be read "table cell", about which end user has no idea. I don't think the above issue is AT tools' fault because HTML table is a little different from what AtkTable defines. IMHO, I don't see any need for HTML table to implement AtkTable interface if they are used to layout the HTML content. In other hand, if HTML table is used to represent a real table in HTML page, e.g. http://www.w3.org/TR/REC-html40/struct/tables.html#h-11.5 , it may need to support AtkTable interface. But there is still issues to be addressed. For example, if the table content are (in most cases) all text - object with no action, user won't see anything after clicking "Table" keyboard in GOK. Based on these, removing AtkTable for HTML table is reasonable and practical at present. If there is any need for HTML table to support AtkTable, we can improve it with other bugs in the future. Phillips, How does Accessibility on Windows to deal with HTML table issue ? Can you give some suggestion on this issue ? Thanks.

Assistive technologies on Windows use heuristics to differentiate between layout and data tables in HTML. Tables have a very simple interface in MSAA. The table object has ROLE_TABLE and all of the children have ROLE_CELL. Beyond that, the assistive technology has to piece together what's happening based on the bounds of each table cell. The AT can also use the DOM or CSS information if it needs to. Generally, the algorithm I've heard from screen reader vendors is: if it has > 2 columns, present it to the user as a data table and enable table navigation. If <=2 columns, don't bother with presenting it as a table. It's probably a layout table in that case anyway, and the table navigation features are not as useful in for only 1 or 2 columns. Another thing that can be used is whether is any border or padding. If there is no border or padding and there are not many columns, it is a strong indicator that this is a layout table. This may not sound ideal, but it works well enough. It's a weakness of HTML that we just have to deal with.

Bill, after disucssion with Aaron, we decide to apply this patch now because it will block many succeeding bug fix if HTML table has "AtkTable" interface. For HTML table, both mozilla and AT-Tools need some update to support "AtkTable" based on discussion above. So I have file a new bug 275010 to deal with this issue specially.

Thanks for r & sr . Patch checked in.