246770 - Hyperlinks is not UI Grabble in GOK

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Louie Zhao]

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.

Comment 1

[Louie Zhao]

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.

Comment 2

[Bill Haneman]

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.

Comment 3

[Louie Zhao]

Attachment: patch v1

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.)

Comment 4

[Bill Haneman]

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

Comment 5

[Louie Zhao]

(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.

Comment 6

[Louie Zhao]

Attachment: sample mozconfig

Comment 7

[Louie Zhao]

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

Comment 8

[Bill Haneman]

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.

Comment 9

[Philip K. Warren]

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

Comment 10

[Louie Zhao]

Attachment: patch_updated

updated patch.

Comment 11

[Louie Zhao]

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 12

[Philip K. Warren]

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"

Comment 13

[Louie Zhao]

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!

Comment 14

[Louie Zhao]

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.

Comment 15

[Aaron Leventhal]

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.

Comment 16

[Louie Zhao]

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.

Comment 17

[Louie Zhao]

Thanks for r & sr . Patch checked in.